System for identifying and applying offers to user transactions

ABSTRACT

An offer processing system is configured to receive transaction data associated with user purchases from third party point of sales devices and/or third party payment processing systems. The offer processing system may then identify offers or savings that are applicable to the transaction data and redeem the offers on behalf of the users.

CROSS-REFERENCE OF RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 15/375,705, filed on Dec. 12, 2016, and entitled“System for Identifying and Applying Offers to Users Transactions,”which is incorporated by reference herein in its entirety.

BACKGROUND

Many merchants offer incentives or discounts to consumers to promoteinterest and purchase of particular goods and services. Unfortunately,many consumers are unaware of the merchant's offers that are intended toentice the consumer into a purchase resulting in a less than effectivemarketing campaign. Additionally, conventional systems fail to provideinexpensive and reliable systems for ensuring and promoting thewidespread distribution of the offers over a communications network orsocial network.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is described with reference to the accompanyingfigures. In the figures, the left-most digit(s) of a reference numberidentifies the figure in which the reference number first appears. Theuse of the same reference numbers in different figures indicates similaror identical components or features.

FIG. 1 illustrates an example offer processing system according to someimplementations.

FIG. 2 illustrates another example offer processing system according tosome implementations.

FIG. 3 illustrates yet another example offer processing system accordingto some implementations.

FIG. 4 illustrates yet another example offer processing system accordingto some implementations.

FIG. 5 illustrates an example offer processing system that aggregatesoffers according to some implementations.

FIG. 6 illustrates an example offer processing system configured totransfer funds according to some implementations.

FIG. 7 illustrates an example offer processing system configured toselect offers for individual users according to some implementations.

FIG. 8 illustrates an example offer processing system configured totrack instances of offers shared with or by individual users accordingto some implementations.

FIG. 9 illustrates an example offer processing system configured totrack a chain of title of an instance of an offer being shared withindividual users according to some implementations.

FIG. 10 illustrates the example offer processing system of FIG. 9configured to track a chain of title of an instance of an offer beingshared with individual users according to some implementations.

FIG. 11 illustrates the example offer processing system of FIG. 9configured to track a chain of title of an instance of an offer beingshared with individual users according to some implementations.

FIG. 12 illustrates the example offer processing system of FIG. 9configured to track a chain of title of an instance of an offer beingshared with individual users according to some implementations.

FIG. 13 illustrates the example offer processing system of FIG. 9configured to track a chain of title of an instance of an offer beingshared with individual users according to some implementations.

FIG. 14 illustrates an example chain of title distributed over aplurality of computing resources being updated over time according tosome implementations.

FIG. 15 illustrates an example offer processing system configured togenerate and redeem travel based offers according to someimplementations.

FIG. 16 is an example timing diagram showing an illustrative process forredeeming offers according to some implementations.

FIG. 17 is another example timing diagram showing an illustrativeprocess for redeeming offers according to some implementations.

FIG. 18 is an example timing diagram showing an illustrative process forsharing offers according to some implementations.

FIG. 19 is another example timing diagram showing an illustrativeprocess for sharing offers according to some implementations.

FIG. 20 is an example timing diagram showing an illustrative process forsharing offers according to some implementations.

FIG. 21 is an example timing diagram showing an illustrative process fortransferring currency via the offer processing system according to someimplementations.

FIG. 22 is another example timing diagram showing an illustrativeprocess for transferring currency via the offer processing systemaccording to some implementations.

FIG. 23 is an example flow diagram showing another illustrative processfor redeeming offers according to some implementations.

FIG. 24 is an example flow diagram showing another illustrative processfor sharing offers according to some implementations.

FIG. 25 is an example flow diagram showing another illustrative processfor generating offers according to some implementations.

FIG. 26 is an example flow diagram showing another illustrative processfor transferring currency according to some implementations.

FIG. 27 is an example flow diagram showing another illustrative processfor generating travel or discount based offers according to someimplementations.

FIG. 28 illustrates an example architecture of one or more serversassociated with an offer processing system according to someimplementations.

FIG. 29 illustrates example components of one or more user deviceshosting a client side application associated with the offer processingsystem according to some implementations.

FIG. 30 is an illustrative example home interface of a client sideapplication of the offer processing system according to someimplementations.

FIG. 31 is an illustrative example user interface for managing paymentcredentials of a client side application of the offer processing systemaccording to some implementations.

FIG. 32 is an illustrative example user interface for entering paymentcredentials into the offer processing system according to someimplementations.

FIG. 33 is an illustrative example wallet interface of a client sideapplication of an offer processing system according to someimplementations.

FIG. 34 is an illustrative example offer search interface of a clientside application of an offer processing system according to someimplementations.

FIG. 35 is an illustrative example offer search interface of a clientside application of an offer processing system according to someimplementations.

FIG. 36 is an illustrative example offer search interface of a clientside application of an offer processing system according to someimplementations.

FIG. 37 is an illustrative example offer search interface of a clientside application of an offer processing system according to someimplementations.

FIG. 38 is an illustrative example offer search interface of a clientside application of an offer processing system according to someimplementations.

FIG. 39 is an illustrative example travel inventory offer interface of aclient side application of an offer processing system according to someimplementations.

FIG. 40 is an illustrative example travel inventory offer interface of aclient side application of an offer processing system according to someimplementations.

FIG. 41 is an illustrative example donation interface of a client sideapplication of an offer processing system according to someimplementations.

FIG. 42 is an illustrative example user interface of a client sideapplication of an offer processing system for transferring currency toother entities according to some implementations.

FIG. 43 is an illustrative example donation interface of a client sideapplication of an offer processing system according to someimplementations.

FIG. 44 is an illustrative example merchant interface associated with anoffer processing system according to some implementations.

FIG. 45 is another illustrative example merchant interface associatedwith an offer processing system according to some implementations.

FIG. 46 is yet another illustrative example merchant interfaceassociated with an offer processing system according to someimplementations.

DETAILED DESCRIPTION

This disclosure includes techniques and implementations associated withan offer processing system that may apply offers, such as cash backoffers, on behalf of users of the offer processing system. For example,the offer processing system may be a third-party cloud-based or serversystem that is configured to aggregate or collect offers (e.g., cashback offers at a retailer) from coupon sites, the merchant systems orsites, marketplace systems or sites as well as to receive offers fromthe merchants via a merchant dashboard or other input system.

In some cases, the offer processing system may receive transaction datafrom third party payment processing systems during the pendency of atransaction (e.g., during a period of time after payment credentialshave been entered at a point of sale device but prior to the approval ofthe transaction by the payment processing system). During this period oftime, the offer processing system may identify a user associated withthe transaction and at least one offer associated with the transaction(e.g., cash back offers for shopping at a retailer) and apply the offerto the transaction.

The payment processing system may send a notification to a user deviceassociated with the user (e.g., via an associated application operatingon the user device) that the user received the benefits of the offer(e.g., in a cash back scenario that the user received an amount of acash back). In some implementations, the value or benefits of the offerapplied to the transaction may be updated via a per user ledger withinthe offer processing system. For example, if the offer was a $5 cashback offer, the $5 may be applied to the user ledger and the user mayreceive a notification of an increase in the ledger by an amount equalto $5. In other cases, the payment processing system may be configuredto transfer the value of the offer to a financial institution associatedwith the user (e.g., a checking or savings account of the user).Additionally, in some implementations, the offer processing system maycredit an amount of less than the full value or benefit of the offer tothe user. For instance, a portion of the value may be provided directlyto a charity and/or collected by the payment processing system as aprocessing or finder's fee.

In some cases, the user may opt in or provide the payment credentialinformation to the offer processing system and provide the offerprocessing system with authorization to receive transaction data fromthe third party payment processing system prior to the system redeemingoffers on the user's behalf. For example, the user may input variouspayment credentials (e.g., credit card information, debit cardsinformation, check routing information, etc.) to authorize the offerprocessing system to receive the transaction data associated with eachof the particular third party payment processing systems.

In some cases, the benefit or the value of the offer applied to thetransaction by the offer processing system may be converted into ajurisdiction neutral currency or offer processing system currency, suchthat the general ledger of each individual may be maintained in thejurisdiction neutral currency. Thus, when a portion of the currency istransferred to a remote institution, individual, or entity, the valuemay be converted into the currency related to the institution,individual, or entity. In this manner, the offer processing systemdisclosed herein removes the necessity of a conventional third partyexchange system and any processing associated with the third partyexchange system required to covert the value between jurisdictions,thereby reducing processing resources associated with transferring valuebetween jurisdiction. In some cases, the offer processing system mayalso reduce or even eliminate exchange fees typically charged to theuser.

Additionally, unlike conventional systems, the offer processing system,disclosed herein, is remote and independent from the point of salessystem, merchant system, coupon settlement system, and paymentprocessing system. In this manner, the system discussed herein maycollect and aggregate offer data, purchase data, user data (e.g., buyinghabits or shopping habits), and/or merchant data. In this example, theaggregation may be performed across payment processing platforms (e.g.,a credit card platform and financial institutions) as well as acrossmerchant systems) and point of sale systems. By collecting andaggregating transaction data as a third party system, the data collectedmay be more complete and accurate. Further, unlike conventional systems,the offer processing system is configured to apply the offer during thependency of the transaction without the input of the user. Thus, theuser is no longer required to activate offers and the merchant,marketplace, social system, or user device is no longer required tostore and track activation data for each user regardless of whether ornot the offer is redeemed. In this manner, the offer processing system,discussed herein, saves processing and data storage resources whencompared with conventional systems. Additionally, as the user no longerneeds to select and apply the offers, the system may be designed withreduced user interface capabilities and/or even, in one particularexample, without a user interface for selecting offers.

Additionally, since the offers are identified and collected by theremote processing system and applied to transactions data received fromthe payment processing system, the merchant is no longer required tocreate platform specific offers over each possible marketplace orretailer. Thus, the offer may be created using one system and usedacross marketplace system, retailer, or other purchasing venue or systemrather than in the conventional sense were an offer is created with eachsocial site, marketplace or vendor. Again, the offer processing system,discussed herein, saves processing and data storage resources overconventional systems.

In some implementations, the offer processing system may allow users toshare offers with others. For instance, in one specific example, uponreceiving notification that value has been added to a first user'sledger, the first user may share the offer redeemed by the paymentprocessing system with a second user, such as the user's friend. In thisexample, the second user may receive a notification from the offerprocessing system related to the offer and when the offer is redeemed bythe second user, the payment processing system may add a portion of thevalue of the offer redeemed by the second user to the ledger associatedwith the first user. Thus, each user of the offer processing system isencouraged to share offers with others in order to receive a portion ofthe value when the offer is redeemed.

In order to track the sharing of the offers between users, the offerprocessing system may create instances of an offer and track a chain oftitle associated with each instance. For instance, in one particularexample, the offer processing system may use block chain system todistribute the chain of title data per instance of an offer overmultiple computing devices (e.g., hundreds of computing devices) in amanner that prevents the chain of title data from being lost or hacked.In one case, as an instance is redeemed and shared, the user data may bestored with each interaction of the instance. The offer processingsystem may walk back up the chain of title when distributing the valueassociated with a redeemed offer. In some cases, the chain of title maybe maintained or built using hash codes.

In some implementations, the offer processing system may be configuredto receive transaction data on a stock keeping unit (SKU) or item levelfrom point of sales devices at a retailer's venue, online merchantshopping cart/checkout system, and/or marketplace shopping cart/checkoutsystems. In this implementation, the offer processing system may beconfigured to apply transaction level offers (e.g., cash back forshopping at a retailer or merchant) as well as item level offers orcoupons (e.g., cash back or discounts for purchasing a particular itemfrom a distributor).

In some particular implementations, the offer processing system may beconfigured to process travel related transactions. In thisimplementation, the offer processing system may purchase inventory froma travel wholesaler system (e.g., a flight or hotel room) at a discount.The offer processing system may convert the discounted purchase priceinto an offer (e.g., as a cash back offer), which may then be shared andredeemed by users. In some cases, the cash back offer generated by theoffer processing system may be based on information collected from othertravel inventory resellers.

FIG. 1 illustrates an example offer processing system 100 according tosome implementations. In the current example, the offer processingsystem 100 is configured to apply offers to transactions associated withusers 102(1)-102(K) of the offer processing system 100. For example, auser 102(1)-102(K) may download a client side application associatedwith the offer processing system 100 on a user device 104(1)-104(L)associated with the user 102(1)-102(K). The user 102(1)-102(K) mayregister or provide payment credentials 106 associated with one or morethird party payment processing systems 108, such as one or more creditor debit cards, to the offer processing system 100 via the client sideapplication on the user device 104(1)-104(L).

The offer processing system 100 may also receive transaction data 110(A)from the third party payment processing systems 108 as the users102(1)-102(K) make purchases at various retailers, online, or otherwise.The transaction data 110(A) may be received during a period of pendencyof the transaction following input of the payment credentials 106 at apoint of sale device (not shown) and approval of the transaction by thethird party payment processing systems 108. In some cases, thetransaction data 110(A) may be received by the third party paymentprocessing system 108 via a vault system 112 or other secure module inorder to protect the confidential and financial data of the users102(1)-102(K).

During the pendency of the transaction, the offer processing system 100may identify the user 102(1) as the user associated with the transactionfrom the group of users 102(1)-102(K). For example, the offer processingsystem 100 may identify the user 102(1) by identifying that the paymentcredentials 106 associated with the transaction data 110(A) correspondto the user 102(1). The offer processing system 100 may also identifyone or more offers that may be applied to the transaction data 110(A).For example, the offer processing system 100 may receive offer data 114from third party merchant systems 116. The offer processing system 100may convert the offer data 114 into an offer (e.g., a cash back offer).The offer may then be applied to the transaction data 110(A) when thetransaction data 110(A) meets or exceeds the criteria for the offer,such as spending more than a threshold amount at a retailer or merchant.The offer processing system 100 may send updated transaction data 110(B)to the third party payment processing system 108 for final approval andpayment to the retailer or merchant.

Once the offer has been identified, the offer processing system 100 maysend redemption data 118 to a third party coupon settlement system 120and/or back to the third party merchant system 116 in order to collectthe value 122 associated with the offer. For example, the third partycoupon settlement system 120 may return or facilitate a transfer of thevalue 122 (e.g., cash back value) from the third party merchant system116 to the offer processing system 100.

Once the value 122 associated with the offer is received by the offerprocessing system 100, the offer processing system 100 may update aledger associated with the user 102(1) to reflect the application of theoffer to a transaction associated with the user 102(1). The offerprocessing system 100 may send a notification 124 to the user 102(1) viathe client side application operating on the user device 104(1) to alertthe user that the ledger has been updated.

In some cases, the offer processing system 100 may only update theledger with a portion of the value less than the total value redeemed.For instance, in some cases, the offer processing system 100 may chargea fee or percentage of the value associated with the offer for applyingthe offer to the transaction on behalf of the user 102(1). In otherinstances, the offer processing system 100 may credit another user102(2)-(K) with a portion of the value 122 of the offer. For example,the user 102(1) may receive the notification 124 and decide to share theoffer with user 102(2). The share data 126 may be received from the userdevice 104(1) and a chain of title may be applied to an instanceassociated with the offer. The offer data 114 may be provided to theuser 102(2). In this example, when the offer processing system 100receives transaction data 110(A) that represents the user 102(2) makinga purchase that qualifies for the offer, the offer processing system 100may redeem the offer, as discussed above, and apply a first portion ofthe value 122 of the offer to the user 102(1) and a second portion ofthe value of the offer to the user 102(2). Thus, unlike conventionalsystems, the offer processing system 100 may encourage or promote thesharing of offers between users 102(1)-(K) and, thereby, moreaffectively distribute the offer throughout users of the system.

In some regards, the share data 126 associated with offers may beaggregated by the offer processing system 100 and provided to each user102(1)-(K) as social data 128. For example, the offer processing system100 may provide social data 128 to each user 102(1)-(K) related to atotal value redeemed by individuals that the user 102(1)-(K) shared theoffer with. For instance, if user 102(1) shared the offer with users102(2), 102(3), and 102(4), the social data 128 provided to the userdevice 104(1) may be a sum of the value redeemed by users 102(2)-102(4)on offers shared with the users 102(2)-(4) by the user 102(1).

In some cases, the value associated with offers being redeemed by theoffer processing system 100 may be distributed to one or more thirdparty financial systems 130 associated with the users 102(1)-102(K)(e.g., a bank or credit union). In these cases, the offer processingsystem 100 may provide transfer instructions 132 to the third partyfinancial system 130 associated or selected by the user 102(1)-(K) totransfer the value 122 from either the third party coupon settlementsystem 120 or the offer processing system 100 to the third partyfinancial system 130.

In some particular implementations, the offer processing system 100 maybe configured to process travel related transactions. In thisimplementation, the offer processing system 100 may purchase inventoryfrom a third party travel wholesaler system 134. In some cases, thethird party travel wholesaler system 134 may sell travel inventory 136(e.g., flights, hotels, excursions, etc.) at a discount. The offerprocessing system 100 may convert the discounted purchase price of thetravel inventory 136 into a cash back offer, which may then be sharedand redeemed by user 102(1).

In some cases, the offer processing system 100 may send or otherwisenotify the users 102(1)-(K) to the existence of an offer, such as whenoffers are shared between users 102(1)-(K). In one particular example,the offer processing system 100 may receive location data 138 from theclient side application operating on the user devices 104(1)-(L). Inthis example, the offer processing system 100 may provide or send offerdata 114 back to the user device 104(1)-(L) based on the location data138, such as all offers within a 5 mile radius of the user device104(1)-(L). In other examples, the user devices 104(1)-(L) may requestor the offer processing system 100 may send offer data 114 related tooffers with threshold values, select merchants or retailers, type ofoffers, etc.

In the illustrated example, the offer processing system 100 is shown ascommunicatively coupled to user devices 104(1)-(L), third party paymentprocessing system 108, third party merchant systems 116, third partycoupon settlement system 120, third party financial systems 130, andthird party travel wholesaler system 134 via networks 140-146. In somecases, the networks 140-146 may be wired technologies (e.g., wires, USB,fiber optic cable, etc.), wireless technologies (e.g., radio frequency(RF), cellular, satellite, Bluetooth, etc.), or other connectiontechnologies. The networks 140-146 are representative of any type ofcommunication network, including data and/or voice network, and may beimplemented using wired infrastructure (e.g., cable, CAT5, fiber opticcable, etc.), a wireless infrastructure (e.g., RF, cellular, microwave,satellite, Bluetooth, etc.), and/or other connection technologies. Thenetworks 140-146 carry data. In the illustrated example, the networks140-146 are shown as separate networks, however, in some cases, thenetworks 140-146 may be the same network, such as the Internet®.

FIG. 2 illustrates another example offer processing system 200 accordingto some implementations. In the current example a user 202 may havestored or registered payment credentials 204 (e.g., credit card or debitcard information) with the offer processing system 200 via a user device206. The user 202 has also made a purchase 208 via a third party pointof sale system 210 using the payment credentials 204.

The transaction data 212 associated with the purchase 208 may betransmitted from the third party point of sale system 210 to a thirdparty payment processing system 214. The third party payment processingsystem 214 may provide the transaction data 212 to the offer processingsystem 200 via a vault system 216 (or other secured and/or encryptedsystem) during a pendency period (e.g., a period associated with thetransaction prior to approval by the third party payment processingsystem 214). In some cases, the vault system 216 may be at third partyvault that is associated with credit card forwarding services to ensureencrypted data transfer. In some alternative examples, the vault system216 may be associated with the third party payment processing system214.

In the current illustration, the offer processing system 200 may hostvarious modules and data for applying offers to transactions. Forexample, the offer processing system 200 may implement a transactionprocessing module 218, an offer redemption module 220, a ledger module222, and a notification module 224. In some cases, the offer processingsystem 200 may also store data, such as offer data 226, user data 228,and/or transaction data 230 to assist with identifying, selecting, andapplying offers on behalf of the user 202. In some cases, the offer data226 may include information associated with multiple offers, the userdata 228 may include user account data, user device data, paymentcredential information (including the payment credentials 204 associatedwith the user 202), purchasing or shopping data, ledger data, etc., andthe transaction data 230 may include data associated with multipletransactions for multiple individual users (e.g., transaction data 212).In some cases, the transaction data 230 and/or user data 228 may beutilized to provide analytics to various merchants to assist with themerchant's marketing research.

In the current example, the transaction processing module 218 mayprocess the transaction data 212 received via the vault system 216. Thetransaction processing module 218 may first identify the user 202 (or anaccount associated with the user 202) as the individual making thepurchase 208. For instance, the transaction processing module 218 mayidentify the user 202 as associated with the transaction data 212 basedat least in part on payment credentials 204 associated with thetransaction data 212 (e.g., the credit card number). For example, thetransaction data 212 received from the payment processing system 214 maybe tokenized and compared with payment credentials 204 stored in atokenized from.

The transaction processing module 218 may also identify one or moreoffers from the offer data 226 that may apply to the transaction data212. For example, the transaction processing module 218 may identify amerchant or retailer associated with the transaction from thetransaction data 212. The transaction processing module 218 may thenidentify offers from the offer data 226 associated with the merchant.For instance, the merchant may be offering a $5 cash back offer on anypurchase of more than $25. In this example, the transaction processingmodule 218 may determine from the transaction data 212 that the purchase208 was for greater than $25 and that the $5 cash back offer was notredeemed at the third party point of sale system 210. The transactionprocessing module 218 may apply the cash back offer and generate updatedtransaction data 232. The updated transaction data 232 may be sent viathe vault system 216 to the third party payment processing system 214for final approval of the transaction. The transaction data 212 and/orthe updated transaction data 232 may be stored as part of thetransaction data 230 for access later by the merchant.

In another specific example, the transaction processing module 218 mayidentify a distributor, item, unit, or service associated with thetransaction from the transaction data 212. The transaction processingmodule 218 may identify offers from the offer data 226 associated withthe distributor, item, unit, or service. For instance, the distributormay be offering a $0.25 cash back offer on an item associated with thepurchase 208. In this example, the transaction processing module 218 maydetermine from the transaction data 212 that the purchase 208 includesthe item and that the $0.25 cash back offer was not redeemed at thethird party point of sale system 210. The transaction processing module218 may apply the cash back offer and generate updated transaction data232. The updated transaction data 232 may be sent via the vault system216 to the third party payment processing system 214 for final approvalof the transaction. The transaction data 212 and/or the updatedtransaction data 232 may be stored as part of the transaction data 230for access later by the distributor. It should be understood, that insome cases, the transaction processing module 218 may apply multipleoffers to the transaction data 212 created or redeemable from multiplesources (e.g., the merchant, retailer, distributor, marketplace, etc.).

Once the offer is identified, the offer redemption module 220 maygenerate and provide redemption data 234 associated with the offer. Theoffer redemption module 220 may also cause the redemption data 234 to besent to a third party coupon settlement system 236 to redeem the offer.The third party coupon settlement system 236 may in response toreceiving the redemption data 234 send value 238 associated with theoffer or cause the value 238 associated with the offer to be transferredto the offer processing system 200.

Once the value 238 is received at the offer processing system 200, theledger module 222 may determine an amount or portion of the value 238 toattribute to the user 202. For example, the ledger module 222 may addall of the value 238 or a portion of the value 238 to a ledgerrepresenting an amount of currency attributable to the user 202currently deposited with the offer processing system 200. In oneparticular example, the transaction processing module 218 may haveidentified an instance of the offer applied to the transaction data 212that was shared with the user 202. In this particular example, theledger module 222 may apply a portion of the value 238 to the ledger ofthe user 202 and a portion to a ledger associated with the user thatshared the offer with the user 202.

Upon receipt of the value 238 and updating of the user's 202 ledger, thenotification module 224 may send a notification 240 to the user device206 associated with the user 202 in order to alert the user 202 to thevalue 238 or portion of the value 238 that was redeemed on the user's202 behalf by the offer processing system 200. For example, thenotification 240 may cause the ledger associated with the user 202 to bepresented on a display of the user device 206. In another example, thenotification 240 may cause the value 238 and/or the offer detailsassociated with the offer redeemed to be presented on a display of theuser device 206.

In the current example, the offer processing system 200, as illustrated,is implemented as one or more cloud-based services or modules hosted onservers 242. In general, cloud-based services refer to a networkaccessible platform implemented as a computing infrastructure ofprocessors, storage, software, data access, and so forth that ismaintained and accessible via a network such as the Internet®. Thecloud-based services do not require end-user knowledge of the physicallocation and configuration of the system that delivers the services.Common expressions associated with cloud services include “on-demandcomputing,” “software as a service (SaaS),” “platform computing,”“network accessible platform” and so forth.

It should be understood that the servers 242 may include various typesof computing devices and may be owned by a single entity and collocatedat a common data center or may be located at separate data centers.Alternatively, the servers 242 may be owned and operated by independententities at separate locations. The servers 242 may be further arrangedin any number of ways, such as server farms, stacks, and the like thatare commonly used in data centers.

FIG. 3 illustrates yet another example offer processing system 300according to some implementations. In some cases, item or unit leveltransaction data from the third party payment processing system may beutilize to redeem offers. In some implementations, the offer processingsystem 300 may receive the transaction data 302 as well as SKU data 304(e.g., item or unit level data) from the third party point of salesystem 306.

In the current illustration, similar to the example above, a user 308may have stored or registered payment credentials 310 (e.g., credit cardor debit card information) with the offer processing system 300 via auser device 312. The user 308 has also made a purchase 314 via the thirdparty point of sale system 306 using the payment credentials 310.

The transaction data 302 and SKU data 304 associated with the purchase314 may be transmitted from the third party point of sale system 306 tothe offer processing system 300 in addition to a third party paymentprocessing system (not shown). The offer processing system 300 mayreceive the transaction data 302 and the SKU data 304 via a vault system316, as discussed above.

A transaction processing module 318 may process the transaction data 302and the SKU data 304 received via the vault system 316. The transactionprocessing module 318 may first identify the user 308 as the individualmaking the purchase 314. For instance, the transaction processing module318 may identify the user 308 as associated with the transaction data302 by comparing the payment credentials 310 associated with thetransaction data 302 to payment credentials 310 stored as part of theuser data 320.

The transaction processing module 318 may also identify one or moreoffers from the offer data 322 that may apply to the transaction data302 or the SKU data 304. For example, the transaction processing module318 may identify a merchant or retailer associated with the transactionfrom the transaction data 302 and an item associated with thetransaction from the SKU data 304. The transaction processing module 318may then identify offers from the offer data 322 associated with themerchant and/or the item.

Once the offers are identified, the offer redemption module 324 maygenerate and provide redemption data 326 associated with the offers. Theoffer redemption module 324 may also cause the redemption data 326 to besent to a third party coupon settlement system 328 to redeem the offer.The third party coupon settlement system 328 may send value 330associated with the offers or cause the value 330 associated with theoffers to be transferred to the offer processing system 300.

Once the value 330 is received at the offer processing system 300, theledger module 332 may determine an amount or portion of the value 330 toattribute to the user 308. For example, the ledger module 332 may add atleast a portion of the value 330 to a ledger representing an amount ofcurrency attributable to the user 308. In one particular example, thetransaction processing module 318 may have identified an instance of theoffer applied to the transaction data 302 that was shared with the user308. In this particular example, the ledger module 332 may apply aportion of the value 330 to the ledger 334 of the user 308 and a portionto a ledger associated with the user that shared the offer with the user308.

Upon receipt of the value 330 and updating of the ledger 334, thenotification module 336 may send a notification 338 to the user device312 associated with the user 308 in order to alert the user 308 to thevalue 330 or portion of the value 330 that was redeemed on the user's308 behalf by the offer processing system 300. For example, thenotification 338 may cause the ledger 334 associated with the user 308to be presented on a display of the user device 312. In another example,the notification 338 may cause the value 330 and/or the offer detailsassociated with the offer redeemed to be presented on a display of theuser device 312.

FIG. 4 illustrates yet another example offer processing system 400according to some implementations. In some implementations, such as thecurrently illustrated implementation, the offer processing system 400may receive some data associated with a transaction, such as thetransaction data 402, from the third party payment processing system 404and other data associated with a transaction, such as the SKU data 406,from the third party point of sale system 408.

In the current illustration, similar to the examples above, a user 410may have stored or registered payment credentials 412 (e.g., credit cardor debit card information) with the offer processing system 400 via auser device 414. The user 410 has also made a purchase 416 via the thirdparty point of sale system 408 using the payment credentials 412.

In this example, the transaction data 402 associated with the purchase416 may be transmitted from the third party point of sale system 408 tothe third party payment processing system 404. The third party paymentprocessing system 404 may provide the transaction data 402 to the offerprocessing system 400 via a vault system 418 during a pendency period(e.g., a period associated with the transaction prior to approval by thethird party payment processing system 404). The third party point ofsale system 408 may also send the SKU data 406 to the offer processingsystem 400 via the vault system 418.

A transaction processing module 420 may process the transaction data 402and the SKU data 406. For instance, the transaction processing module420 may identify the user 410 as the individual making the purchase 416from the transaction data 402 and the user data 424. The transactionprocessing module 420 may also identify one or more offers from theoffer data 426 that may apply to the transaction. For example, thetransaction processing module 420 may identify a merchant or retailerassociated with the transaction from the transaction data 402 and adistributor associated with the transaction from the SKU data 406. Thetransaction processing module 420 may then identify offers from theoffer data 426 associated with the merchant and/or the distributor.

Once the offers are identified, the offer redemption module 428 maygenerate and provide redemption data 430 associated with the offers. Theoffer redemption module 428 may also cause the redemption data 430 to besent to a third party coupon settlement system 432 to redeem the offer.The third party coupon settlement system 432 may send value 434associated with the offers or cause the value 434 associated with theoffers to be transferred to the offer processing system 400.

Once the value 434 is received at the offer processing system 400, theledger module 436 may determine an amount or portion of the value 434 toattribute to the user 410 and apply the portion of the value to theledger associated with the user 410. The notification module 438 mayalso send a notification 440 to the user device 414 associated with theuser 410 in order to alert the user 410 to the portion of the value 434that was redeemed on the user's 410 behalf by the offer processingsystem 400.

FIG. 5 illustrates an example offer processing system 500 in the processof aggregating offers 502 according to some implementations. Forexample, the offer data 502 may be collected from various sources, suchas third party merchant systems 504, marketplace systems 506, couponsystems 508, and/or distributor systems 510. In some cases, the offerdata 502 may be aggregated from the sources 504-510 and applied totransaction data received from third party point of sales systems (notshown) and/or third party payment processing systems (not shown).

In the illustrated example, the offer processing system 500 mayimplement or host various modules for the collection of offer data 502.For instance, the offer processing system 500 may include a merchantplatform module 512. The merchant platform module 512 may allowmerchants 504, marketplaces 506, or distributors 508 to create offersand/or offer campaigns with the offer processing system 500. Forexample, the merchant 504 or marketplace 506 may utilize the merchantplatform module 512 to create cash back offers associated with shoppingat particular retail establishments or online venues. Similarly, thedistributors 508 may create offers associated with purchasing aparticular item, unit, or service offered by the distributor 508regardless of the merchant 504 or marketplace 506 utilized to purchasethe item, unit, or service. In some cases, the offers may be createdelectronically using a merchant interface of the offer processingsystem.

Similarly, the offer processing system 500 may implement or host anoffer identification module 514. The offer identification module 514 maybe configured to search and locate the offer data 502 associated withcurrent valid offers provided by the sources 504-510. For example, theoffer identification module 514 may identify offers on various items,retail locations, online venues, etc. by searching networks 516 and 518for the offer data 502 on various websites. For instance, in oneparticular example, the offer identification module 514 may locate andcollect offer data 502 associated with offers posted on the Internet®.

In some implementations, the offer processing system 500 may include anoffer generation module 520. For instance, the offer generation module520 may create offers based on the offer data 502 collected by the offeridentification module 520. For example, the offer identification module514 may identify discount or wholesale goods (e.g., via a travelwholesaler system). The offer generation module 520 may convert thediscounted price or wholesale price of the goods into an offerredeemable by users 522(1)-(K). In one particular implementation, theoffer generation module 520 may be configured to purchase discounteditems, units, inventory, or services and to generate offers to purchasethe discounted items, units, inventory, or services via the offerprocessing system 500.

In some implementations, the offer processing system 500 may alsoinclude an offer selection module 524. In this implementation, the offerselection module 524 may select offers to send to user devices526(1)-(L) associated with the users 522(1)-(K) based at least in parton the offer data 502 and user data 528. For example, the user data 528may include location data 530 received from one or more of the userdevices 526(1)-(L). The offer selection module 524 may select and sendoffers within a threshold distance of the corresponding user device526(1)-(L). For example, the offer may include savings associated with agas station within five miles of the corresponding user device526(1)-(L).

In one particular example, the offer selection module 524 may identifyand send offers to user devices 526(1)-(L) when the offer data 502 isshared between the users 522(1)-(K). In this particular example, a chainof title module 532 associated with the offer processing system 500, maycreate and track instances of the offers, as will be discussed in moredetail below with respect to FIGS. 7-14 .

The offer processing system 500 may also host or implement a merchantdashboard module 534. The merchant dashboard module 534 may allow themerchant 504, marketplace 506, coupon system 508, or distributor 510 totrack the effectiveness of an offer, such as a redemption rate, asharing rate, a view or impression rate, etc. In some cases, themerchant dashboard module 534 may convert the redemption rate into arevenue versus expense metric using the offer data 502, user data 528,and transaction data received from third party payment processingsystems (not shown) and/or third party point of sale systems (notshown).

FIG. 6 illustrates an example offer processing system 600 configured totransfer funds according to some implementations. In the currentexample, the offer processing system 600 may include a ledger module 602that is configured to maintain a user specific ledger 604 in relation touser data 606 associated with each user 608(1)-(K). The user specificledger 604 may represent an amount or value of currency that the user608(1)-(K) has acquired as the offer processing system 600 appliesoffers to purchases made by the user 608(1)-(K) using registered paymentcredentials.

In the illustrated example, one of the users 608(1)-(K), such as user608(1), may desire to transfer some of the currency represented by theledger 604 to a third party financial system 610. For instance, the user608(1) may desire to transfer currency into a savings or checkingaccount with a banking system 614, pay a bill at a payment processingsystem 614, a marketplace system 616, or merchant system 618. The user608(1) may also desire to donate currency to a charity system 620. Inthis example, the user 608(1) may utilize a user device, such as userdevice 622(1), to send transfer request 624 to the offer processingsystem 600. The transfer request 624 may be received by a currencytransfer module 626 of the offer processing system 600. In onealternative example, the user 608(1) may also transfer currency via thecurrency transfer module 626 to gift cards, store credit accounts,prepaid-cards, or general purpose reloadable payment cards.

The currency transfer module 626 may access account data 628, such as asavings account number, and generate transfer instruction 630. Thetransfer instructions 630 may be provided to the third party financialsystem 610 to affect the transfer of the currency from the ledger 604 tothe third party financial system 610. In some cases, the offerprocessing system 600 may receive a confirmation 632 in responseconfirming receipt of the currency at the third party financial system610. Once the confirmation 632 is received, the offer processing system600 may provide a notification 634 to the user device 622(1) to alertthe user 608(1) that the transfer is complete.

In some cases, the ledger 604 may be maintained in a jurisdictionindependent currency of the offer processing system 600. In these cases,the offer processing system 600 may include an exchange module 636. Theexchange module 636 may be configured to determine a current exchangerate of the offer processing system currency with regards to a currencyassociated with the third party financial system 610. For example, theexchange module 636 may determine the currency associated with the thirdparty financial system 610 is the pound and convert the currencyrepresented by the ledger 604 into pounds prior to transferring thefunds to the third party financial system 610. In other cases, theledger 604 may be maintained in the currency associated with the user608(1). In this case, the ledger 604 may be in US dollars and whentransferred to the third party financial system 610 may be convertedinto pounds by the exchange module 636. In some cases, by converting thecurrency to the currency of the receiving party prior to processing thetransaction, in addition to saving the user 608(1) an exchange fee, theoffer processing system 600 may reduce the processing required to affectthe transfer by removing the necessity of involving a conventionalexchange system.

In the current example, it should be understood that the systems 612-620may be part of the same financial system 610 or independent systems.

FIG. 7 illustrates an example offer processing system 700 configured toselect offers, such as offers 702(1)-(N), for individual users, such asusers 704(1)-(K), according to some implementations. In the illustratedexample, the offer processing system 700 may include an offeridentification module 706 and an offer generation module 708 to catalogand create offers 702, as discussed above with respect to FIG. 5 . Eachof the offers 702(1)-(N) may have a corresponding merchant 710(1)-(N), avalue 712(1)-(N), and a chain of title 714(1)-(N). The chain of title714(1)-(N) is used to track the sharing, origination and redemption ofthe offers 702, as will be discussed in more detail below with respectto FIGS. 8-14 . It should also be understood that the merchants710(1)-(N) and the values 710(1)-(N) associated with various offers702(1)-(N) may be the same.

The offer processing system 700 may also include an offer selectionmodule 716 to select offers 702 to send to the users 704(1)-(K) based atleast in part on user data 718. For instance, the offer selection module716 may select offer A 702(1) to send to user 704(1), offer B 702(2) tosend to user 704(2), and offer C 702(N) to send to user 704(K) based ona distance of each of the users 704(1)-(N) to a merchant 710(1)-(N)associated with each of the offers 702(1)-(N). As each offer 702(1)-(N)is shared or sent to the users 704(1)-(K), the chain of title module 720may update the chain of title 714(1)-(N) associated with the offer702(1)-(N).

FIG. 8 illustrates an example offer processing system 800 configured totrack instances of offers 802 shared with or by individual users804(1)-(K) according to some implementations. Similar to the example ofFIG. 7 , the offer processing system 800 may include an offeridentification module 806 and an offer generation module 808 to catalogand create offer data 802 and an offer selection module 810 to selectoffers 802 to send to the users 804(1)-(K) based at least in part onuser data 812.

However, in the current example, the offer selection module 810 hasselected the same offer 802 to send to each of the users 804(1), 804(2),and 804(K). In this case, each of the users 804(1), 804(2), and 804(K)may receive a difference instance 814(1), 814(2), and 814(N)representing an offer having the same merchant 816 (or merchantidentifier) and the same value 818 but a different or unique chain oftitle 820(1)-(N). As discussed above, the chain of title 820(1)-(N) isused to track the sharing, origination and redemption of each instance814(1)-(N) of the offer 802. As each instance 814(1)-(N) may have adifferent sharing history. Starting with the offer processing system 800sending the instances 806(1)-(N) to the various users devices 822(1)-(L)associated with the various users 804(1)-(K), as illustrated. Thus, aseach offer instance 814(1)-(N) is shared or sent to the user devices824(1)-(L) of the users 804(1)-(K), the chain of title module 824 mayupdate the chain of title 820(1)-(N) to reflect the sharing andredemption activity.

FIG. 9 illustrates an example offer processing system 900 configured totrack a chain of title 902 of an instance 904 of offer 906 being sharedwith individual users 908(1) and 908(2) according to someimplementations. In this example, the instance 904 of the offer 906associated with a merchant 910 and having a value 912 may have beencreated by either the offer identification module 914 or the offergeneration module 916. The offer selection module 918 may determine thatthe instance 904 of the offer 906 should be sent to the user 908(1)based on the user data 920 via the user device 922(1). In this case, thechain of title module 924 may update the chain of title 902 of aninstance 904 of the offer 906 to show that the instance 904 was sharedor sent by the offer processing system 900 to the user 908(1).

FIG. 10 illustrates the example offer processing system 900 of FIG. 9configured to track a chain of title 902 of an instance 904 of offer 906being shared with individual users 908(1) and 908(2) according to someimplementations. In the illustrated example, the user 908(1) hasreceived the instance 904 of the offer 906 at the user device 922(1) anddetermined that the user 908(2) may desire to utilize or redeem theoffer 906. Thus, the user 908(1) may cause the user device 922(1) tosend a share request 1002 to the offer processing system 900 to cause ashare module 1004 of the offer processing system 900 to share details ofthe offer 906 with the user 908(2).

FIG. 11 illustrates the example offer processing system 900 of FIG. 9configured to track a chain of title 902 of an instance 904 of offer 906being shared with individual users 908(1) and 908(2) according to someimplementations. In the present example, the share request 1002 has beenreceived and processed by the share module 1004 and the chain of title902 has been updated by the chain of title module 924 to show that theuser 908(1) caused the instance 904 of the offer 906 to be shared withthe user 908(2). In this case, the instance 904 was updated as the chainof title module 924 determined from the chain of title 902 that instance904 was the version of the offer 906 provided or viewed by the user908(1).

FIG. 12 illustrates the example offer processing system 900 of FIG. 9configured to track a chain of title 902 of an instance 904 of offer 906being shared with individual users 908(1) and 908(2) according to someimplementations. In the current example, the instance 904 has beenshared with the user 908(2) and the user 908(2) is in the process ofmaking a purchase at a third party point of sale system 1202 associatedwith the offer 906.

As discussed above, the transaction data 1204 is provided to a thirdparty payment processing system 1206 which in turn provides thetransaction data 1204 to the offer processing system 900 via a vaultsystem 1208. A transaction processing module 1210 may identify the user908(2) as associated with the transaction data 1204 via user data 920(e.g., via stored payment credentials). The transaction processingmodule 1210 may also determine the offer 906 is applicable to thepurchase represented by the transaction data 1204. The offer redemptionmodule 1212 may cause a coupon settlement system (not shown) to transfera value 912 associated with the offer 906 to the offer processing system900.

The chain of title module 924 may determine that there was a version ofthe offer 906 shared with the user 908(2) and that the version wasinstance 904. The chain of title module 924 may also determine that theuser 908(1) shared the instance 904 of the offer 906 with the user908(2). In this case, the chain of title module 924 may alert the ledgermodule 1214 that the user 908(1) shared the offer 906 with the user908(2) and the ledger module 1214 may apply a portion of the value 912to the ledger of the user 908(1) to reflect the sharing of the offer906. Thus, by utilizing an offer processing system 900 that tracks chainof title 902 per instance 904 of an offer 906, the value 912 redeemed onthe offer 906 may be shared between individual users 908 in a mannerthat prevents fraud.

In some cases, the chain of title module 924 may be distributed overmultiple devices or servers and operate under a block chain scheme.Thus, in these cases, the chain of title 902 associated with theinstance 904 may be distributed as a plurality of copies over thevarious devices and servers. In some cases, if a particular copy of thechain of title 902 fails to match or validate correctly, the particularcopy may be discarded from the system.

It should also be understood, that in some cases, the ledgers or legerdata associated with each individual user 908 may also be distributed.In this example, each ledger may be distributed as a plurality of copiesover multiple devices and servers. In some cases, if a particular copyof the ledger fails to match or validate correctly with respect to theother copies, the particular copy may be discarded from the system. FIG.13 illustrates the example offer processing system 900 of FIG. 9configured to track a chain of title 902 of an instance 904 of offer 906being shared with individual users 908(1) and 908(2) according to someimplementations. In the current illustration, the ledger module 1212 hasupdated the ledger of user 908(1) with the first portion of the value912 and the ledger of user 908(2) with the second portion of the value912 redeemed by applying the offer 906 to the purchase of the user908(2). A notification module 1302 may then be configured to send anotification 1304(1) to the user device 922(1) associated with the user908(1) indicating the addition of the first portion of the value 912 tothe user's 908(1) ledger. Similarly, the notification module 1302 maysend a notification 1304(2) to the user device 922(2) associated withthe user 908(2) indicating the addition of the second portion of thevalue 912 to the user's 908(2) ledger.

FIG. 14 illustrates an example chain of title 1402 distributed over aplurality of computing resources, generally indicated by 1404, beingupdated over time, T1 1406, T2 1408, and T3 1410, according to someimplementations. For instance, at the time T1 1406, a first user mayshare an instance of an offer that was redeemed or presented to thefirst user by an offer processing system. Thus, the offer processingsystem may update the chain of title to reflect the sharing of theinstance from the first user to the second user. Next at a time T2 1408,the second user may again share the offer with a third user. Again, theoffer processing system may update the chain of title to reflect thesharing of the instance from the second user to the third user.

At a time T3 1408, the third user may complete a purchase that meets orexceeds the criteria of the offer represented by the instance of theoffer. For example, as discussed above, the offer processing system mayreceive transaction data from either or both of a third party point ofsale device and/or a third party payment processing system and determinethat the purchase meets or exceeds the criteria of the offer. In thiscase, once the offer processing system receives value associated withthe offer, the offer processing system may distribute the offer inportions to the first, second, and third user by determining that thechain of title 1402 is valid and that each of the first, second andthird user were involved with the third user making a purchase to redeemthe offer.

In some cases, the chain of title 1402 may include an original uniquenode, generally indicated by 1412, that may be utilized to validate thatthe instance and chain of title 1402 is valid. In some cases, theoriginal unique node 1412 may include a time stamp that invalidates theinstance represented by the chain of title 1402. For example, if thethird user's purchase was performed more than three months fromreceiving the shared offer, the first user and the second user may notbe entitled to receive portions of the value redeemed as it is unlikelythe third user made the purchase in response or because of the sharingof the instance. In some implementations, copies of the chain of title1402 associated with each instance of an offer may be stored in adistributed manner over the computing resources 1404. In theseimplementations, the chain of title 1402 may be considered valid if eachof the copies or greater than a threshold percentage of the copies arevalid. In this manner, the offer processing system may avoid tamperingwith the chain of title 1402 and prevent unauthorized distribution ofportions of offer value redeemed by the offer processing system. Inother cases, the chain of title 1402 may be effected by generatingunique hash codes for each interaction with the chain of title 1402. Theoffer processing system may then validate the chain of title 1402 basedon the hash codes associated with the chain of title.

FIG. 15 illustrates an example offer processing system 1500 configuredto generate and redeem travel based offers according to someimplementations. In the illustrated example, the offer processing system1500 may include an offer generation module 1502. The offer generationmodule 1502 may be configured to receive travel data 1504 associatedwith discounted or wholesale inventory available for purchase from athird party travel wholesaler system 1506. A competitor module 1508 orthe offer generation module 1502 may also be configured to retrieve orreceive competitive pricing data 1510 from third party travel systems1512, such as a travel reseller system or travel merchant site.

The offer generation module 1502 may generate offers 1514 based at leastin part on the competitive pricing 1510 and the wholesale price of theinventory. For example, the offer generation module 1502 may determine adifference between the competitive pricing 1510 of the inventory and thewholesale price of the same inventory item. The offer generation module1502 may then convert the difference or a portion of the difference intoa cash back offer 1514. For instance, in one particular example, a hotelroom that is available on the wholesaler system 1506 for $150 may be forsale at the third party travel system 1512 for $200. From this data, theoffer generation module 1502 may generate an offer 1514 to purchase thehotel room for $200 with a $50 cash back when purchased via the offerprocessing system 1500. Alternately, the offer generation module 1502may generate an offer 1514 to purchase the hotel room for $200 with a$25 cash back when purchased via the offer processing system 1500. Inyet another example, the offer generation module 1502 may generate anoffer 1514 to purchase the hotel room for $175 with a $25 cash back whenpurchased via the offer processing system 1500.

Once the offer generation module 1502 generates an offer 1514 based onthe competitive pricing 1510 and the travel data 1504 received from thethird party travel wholesaler system 1506, the offer 1514 may beprovided to a user's device 1516 to alert a user 1518 to the existenceof the offer 1514. In some cases, the offer 1514 may be sent to the userdevice 1516 in response to a request for pricing or offers related to aparticular travel inventory or item. In one particular example, theoffer 1514 may be generated (e.g., the competitive pricing 1510determined and the travel data 1504 retrieved) in response to a requestfor pricing or offers related to a particular travel inventory or item.Thus, the offer processing system 1500 may operate to generate offers insubstantially real time based on requests or searches received from theuser devices 1516.

Additionally, once the offer 1514 is generated and sent to the userdevice 1516, the user 1518 may share 1520 the offer 1514 or book theoffer 1514. In one particular case, the ledger module 1524 may beconfigured to receive the booking data 1522 from the user device 1516and to cause the value represented by the ledger associated with theuser 1518 to reflect the booking data 1522. For example, if the user1518 booked the $200 hotel room then the ledger module 1524 may convertthe offer system currency reflected in the ledger to US dollars andsubtract the $200 or cause the $200 to be transferred to the wholesalersystem 1506 in order to purchase the room. The ledger may also creditthe ledger with the $50 saving associated with the offer 1514. In oneparticular example, the ledger module 1524 may subtract the $150 fromthe user's ledger, as the value of the offer 1514 does not need to beredeemed from a third party system. Thus, the offer processing system1500 may reduce any overhead associated with debiting and crediting theledger. Once the offer value is credited to the user's ledger, anotification module 1526 may send a notification 1528 to the user device1516 to alert the user 1518 to the credit, as discussed above.

FIGS. 16-22 are timing diagrams illustrating example flows associatedwith the offer processing system of FIGS. 1-15 according to someimplementations. The processes are illustrated as a collection of blocksin a logical flow diagram, which represent a sequence of operations,some or all of which can be implemented in hardware, software or acombination thereof. In the context of software, the blocks representcomputer-executable instructions stored on one or more computer-readablemedia that, which when executed by one or more processors, perform therecited operations. Generally, computer-executable instructions includeroutines, programs, objects, components, encryption, deciphering,compressing, recording, data structures and the like that performparticular functions or implement particular abstract data types.

FIG. 16 is an example timing diagram showing an illustrative process1600 for redeeming offers according to some implementations. As shown inthe illustrated example, the process 1600 is performed over times T1-T8by actors, such as a first user 1602, the offer processing system 1604,a third party payment processing system 1606, a second user 1608, and amerchant or merchant system 1610.

Initially at 1612 and a time T1, the offer processing system 1604 maydetect an offer. For example, the offer processing system 1604 maydetect an offer that is published to the Internet® or another networkvia one or more web-crawls or offer detection modules. In another case,such as discussed above with respect to FIG. 15 , the offer processingsystem 1604 may generate an offer by converting a discount or wholesaleprice of an item, unit, inventory, or service into a cash back offer.

Alternatively, at 1614 and at time T1, the merchant 1610 may create theoffer. For example, the merchant 1610 may access a merchant dashboard orplatform, as discussed above with respect to FIG. 5 , to generate anoffer or an offer campaign (e.g., multiple offers or offers presentedbased on thresholds, such as redemption numbers or time).

At 1616 and time T2, the first user 1602 may purchase an item. Forexample, the user 1602 may utilize payment credentials stored with theoffer processing system 1604 to make a purchase at a point of saledevice (not shown). In some cases, the purchase may meet or exceed oneor more criteria associated with the offer detected at 1612 or createdat 1614.

At 1618 and at time T2, transaction data associated with the purchase ofthe first user 1602 is received by the third party payment processingsystem 1606. The third party payment processing system 1606 may thenprovide the transaction data to the offer processing system 1604 duringthe pendency of the transaction or prior to final approval of thetransaction.

At 1620 and time T3, the offer processing system 1604 may receive thetransaction data from the third party payment processing system 1606. At1622 and T4, the offer processing system 1604 may detect that thetransaction data meets or exceeds the requirements of the offer and thatthe transaction is associated with the first user 1602. For example, theoffer processing system 1604 may detect the stored payment credentialsare being used to process the transaction represented by the transactiondata.

At 1624 and time T5, the offer processing system 1604 may and update thetransaction data to apply the offer to the transaction, and, at 1626,the offer processing system 1604 may send and the third party paymentprocessing system 1606 may receive the updated transaction data. Thethird party payment processing system 1606 may then complete or approvethe transaction.

At 1628 and time T6, the offer processing system 1604 may update theledger associated with the first user 1602. For example, the offerprocessing system 1604 may redeem the offer via a coupon settlementcompany. When the value is received the offer processing system 1604 maydetermine what portion of the value is to be credited to the first user1602 and then update the user's ledger accordingly.

At 1630, 1632, and at time T7, the offer processing system 1604 may sendand the first user 1602 may receive a notification as to the value thatis credited to the first user's ledger. In some cases, the notificationmay be sent to a user device implementing a client side or userapplication.

At 1634, the first user 1602 may cause the offer processing system 1604to share the offer with another user, such as the second user 1608. Insome cases, the notification received at 1632 may cause the user deviceto alert the first user 1602 to the credit and present the first user1602 with the option to share the offer with one or more connectedindividuals, such as the second user 1608.

FIG. 17 is another example timing diagram showing an illustrativeprocess 1700 for redeeming offers according to some implementations. Asshown in the illustrated example, the process 1700 is performed overtimes T1-T7 by actors, such as a first user 1702, the offer processingsystem 1704, a third party point of sale system 1706, a second user1708, and a merchant or merchant system 1710.

Initially at 1712 and a time T1, the offer processing system 1704 mayidentify an offer. For example, the offer processing system 1704 maydetect an offer that is published to the Internet® or another networkvia one or more web-crawls or offer detection modules. In another case,such as discussed above with respect to FIG. 15, the offer processingsystem 1704 may generate an offer by converting a discount or wholesaleprice of an item, unit, inventory, or service into a cash back offer.

Alternatively, at 1714 and at time T1, the merchant 1710 may create theoffer. For example, the merchant 1710 may access a merchant dashboard orplatform, as discussed above with respect to FIG. 5 , to generate anoffer or an offer campaign (e.g., multiple offers or offers presentedbased on thresholds, such as redemption numbers or time).

At 1716 and time T2, the first user 1702 may purchase an item. Forexample, the user 1702 may utilize payment credentials stored with theoffer processing system 1704 to make a purchase at a point of saledevice 1706. In some cases, the purchase may meet or exceed one or morecriteria associated with the offer detected at 1712 or created at 1714.

At 1718 and at time T2, payment credentials associated with the purchaseof the first user 1702 is processed by the third party point of salesystem 1706. The third party point of sale system 1706 may then providethe SKU data associated with the purchase to the offer processing system1704. In some cases, the third party point of sale system 1706 may alsoprovide transaction data to the offer processing system 1704 togetherwith the SKU data.

At 1720 and time T3, the offer processing system 1704 may receive theSKU data from the third party payment processing system 1706. At 1722and T4, the offer processing system 1704 may detect that the SKU datameets or exceeds the requirements of the offer (e.g., the purchase of aparticular item or unit) and that the transaction is associated with thefirst user 1702. For example, the offer processing system 1704 maydetect the stored payment credentials are being used to process thetransaction represented by the transaction data.

At 1724 and time T5, the offer processing system 1704 may update theledger associated with the first user 1702. For example, the offerprocessing system 1704 may redeem the offer via a coupon settlementcompany. When the value is received the offer processing system 1704 maydetermine what portion of the value is to be credited to the first user1702 and then update the user's ledger accordingly.

At 1726, 1728, and at T6, the offer processing system 1704 may send andthe first user 1702 may receive a notification as to the value that iscredited to the first user's ledger. In some cases, the notification maybe sent to a user device implementing a client side or user application.

At 1730 and time T7, the first user 1702 may cause the offer processingsystem 1704 to share the offer with another user, such as the seconduser 1708. In some cases, the notification received at 1728 may causethe user device to alert the first user 1702 to the credit and presentthe first user 1702 with the option to share the offer with one or moreconnected individuals, such as the second user 1708.

FIG. 18 is an example timing diagram showing an illustrative process1800 for sharing offers according to some implementations. As shown inthe illustrated example, the process 1800 is performed over times T1-T8by actors, such as a first user 1802, the offer processing system 1804,a third party payment processing system 1806, a second user 1808, and amerchant or merchant system 1810. In this particular example, the firstuser 1802 is sharing an offer with the second user 1808 whom in turnmakes a purchase that meets or exceeds the criteria associated with theoffer.

At 1812, 1814, and at time T1, the first user 1802 may cause the offerprocessing system 1804 to share the offer with another user, such as thesecond user 1808. For example, the first user 1802 may have received anotification related to the offer and thought that the second user 1808would be interested.

At 1816 and time T2, the offer processing system 1804 may update a titleassociated with an instance of the offer. The chain of title may beutilized to track the sharing, viewing, and redemption of the offer withrespect to user's social interactions. For example, the offer processingsystem 1804 may divide any value redeemed in association with an offerapplied based on the chain of title or social sharing information.

At 1818 and time T3, the second user 1808 may receive the share of theoffer. For instance, the offer may be presented to the second user 1808via a second user device associated with the second user 1808 andimplementing a client side application.

At 1820, 1822, and time T4, the second user 1808 may make a purchasethat meets or exceeds the criteria of the offer at a point of saledevice (not shown) using payment credentials stored with the offerprocessing system 1804. Transaction data associated with the purchase ofthe second user 1808 is received by the third party payment processingsystem 1806. The third party payment processing system 1806 may thenprovide the transaction data to the offer processing system 1804 duringthe pendency of the transaction or prior to final approval of thetransaction.

At 1824 and time T5, the offer processing system 1804 may receive thetransaction data from the third party payment processing system 1806. At1826 and T6, the offer processing system 1804 may detect that thetransaction data meets or exceeds the requirements of the offer and thatthe transaction is associated with the second user 1808. For example,the offer processing system 1804 may detect the stored paymentcredentials are being used to process the transaction represented by thetransaction data.

At 1828 and time T7, the offer processing system 1804 may determine fromthe chain of tittle that the first user 1802 shared the offer with thesecond user 1808 prior to the second user 1808 completing a purchasethat met or exceeded the criteria of the offer.

At 1830 and time T8, the offer processing system 1804 may update aledger associated with the first user 1802 and a ledger associated withthe second user 1808. For instance, once the offer processing system1804 determines that the offer was shared by the first user 1802 withthe second user 1808 and that the chain of title is valid, the offerprocessing system 1804 may allocate a portion of the value of the offerto the first user 1802 and the remainder of the value to the second user1808.

FIG. 19 is another example timing diagram showing an illustrativeprocess 1900 for sharing offers according to some implementations. Asshown in the illustrated example, the process 1900 is performed overtimes T1-T8 by actors, such as a first user 1902, the offer processingsystem 1904, a third party payment processing system 1906, a second user1908, and a merchant or merchant system 1910.

In this particular example, at 1912 and time T1, the offer processingsystem 1904 has updated the ledgers associated with the first user 1902and the second user 1908 after the second user 1908 made a purchase thatqualified for an offer shared with the second user 1908 by the firstuser 1902. For instance, once the offer processing system 1904determines that the offer was shared by the first user 1902 with thesecond user 1908 based on a valid chain of title, the offer processingsystem 1904 may allocate a portion of the value of the offer to thefirst user 1902 and the remainder of the value to the second user 1908.

At 1914 and time T2, the offer processing system 1904 sends the firstuser 1902 a first notification as to the portion of the value creditedto the first user's ledger and the second user a second notification asto the remaining portion of the value credited to the second user'sledger. In some cases, the notification may be sent to a user deviceimplementing a client side or user applications.

At 1916, 1918, and time T3, the first user 1902 receives the firstnotification and the second user 1908 receives the second notification.For instance, the first user device may alert the first user 1902 to thefirst notification by vibrating, emitting an audible noise or sound,flashing a light, etc. Similarly, the second user device may alert thesecond user 1908 to the second notification.

At 1920 and T4, the offer processing system 1904 may update merchant oroffer data. For instance, the offer processing system 1904 may collectanalytics or data associated with each offer redeemed, each offershared, revenue generated based on offers, user shopping habits and/orlocation, purchase time and dates, payment system usages, among others.

At 1922 and time T5, the merchant 1910 may access the offer processingsystem 1904 or send a request to the offer processing system 1904 toview the offer data being aggregated or collected by the system 1904.For example, the merchant 1910 may desire to view an amount of sharingassociated with a particular offer, an amount of value redeemed on anoffer, an amount of revenue generated from purchases associated withoffers, types of users redeeming offers, etc.

At 1924 and time T6, the offer processing system 1904 may receive therequest from the merchant 1910 and, at 1926 and time T7, send therequested data to the merchant system 1910 making the request. In somecases, the offer processing system 1904 may process the offer data priorto sending the requested data to the merchant system 1910. And, at 1928and time T8, the merchant 1910 may view the offer data.

FIG. 20 is an example timing diagram showing an illustrative process2000 for sharing offers according to some implementations. As shown inthe illustrated example, the process 2000 is performed over times T1-T8by actors, such as a first user 2002, the offer processing system 2004,a third party payment processing system 2006, a second user 2008, and amerchant or merchant system 2010. In this example, the offer processingsystem 2004 is providing or sending offers to the user 2002 based oninformation known about the user 2002, such as location data receivedfrom a user device associated with the user 2002.

At 2012 and time T1, the user device hosting a client side applicationmay transmit location data, such as global position satellite (GPS)data, wifi data, wireless communication network data (e.g., connectedtower ID), among others to the offer processing system 2004. However, inother examples, it should be understood that the offer processing system2004 may receive or store other data associated with the users 2002 and2008, such as buying habits, previous purchase data, venue or merchantdata (e.g., repeat purchases at the same venue), time/date data (e.g.,similar purchases at similar times and dates), etc.

At 2014 and time T2, the offer processing system 2004 may receive thelocation data from the user device and, at 2016 and time T3, the offerprocessing system 2004 may identify one or more offers that may be ofinterest to the user 2002 based on the location data. For example, theoffer processing system 2004 may select offers within a thresholddistance of the user 2002 or offers that are located at venues on apredicted travel path of the user 2002. For instance, in one particularexample, the offer processing system 2004 may determine from thelocation data and time data that the user 2002 is driving to work. Theoffer processing system 2004 may also be aware that the user 2002typically stops for coffee on the drive to work based on previouspurchase history. Thus, the offer processing system 2004 may identifyoffers for coffee at venues along the user's 2004 route to work orwithin a threshold distance of the route to work.

At 2018, 2020, and time T4, the offer processing system 2004 may sendand the user device associated with the user 2002 may receive offer dataor the offer identified as of interest to the user 2002 by the offerprocessing system 2004. For example, an application operating on theuser device may present the offers as a visual indication on a map, suchas together with navigation information.

At 2022 and time T5, the user may make a purchase corresponding to theoffer via a third party point of sale device at the venue selected, asdiscussed above. At 2024, a third party payment processing system 2006may receive the transaction data associated with the purchase. At 2026and T6, the third party payment processing system 2006 may provide andthe offer processing system 2004 may receive the transaction data. Forinstance, the transaction data may be accessible to the offer processingsystem 2004 during the pendency of the transaction or prior to finalapproval of the transaction by the third party payment processing system2006.

At 2028 and time T7, the offer processing system 2004 may process thetransaction data. For example, the offer processing system 2004 maydetermine that the transaction data meets or exceeds the criteria of theoffer shared with the user 2002. The offer processing system 2004 mayalso determine that the transaction data is associated with the user2002 and cause the offer to be redeemed from a third party couponsettlement company, merchant, or distributor on behalf of the user 2002.The offer processing system 2004 may then apply the value of the offeror a portion of the value of the offer to the user's 2002 ledger.

At 2030, 2032, and time T8, the offer processing system 2004 may sendand the user device associated with the user 2002 may receive anotification to alert the user 2002 that the transaction data meets orexceeds the requirements of the offer and a value has been redeemed andadded to the user's 2002 ledger within the offer processing system 2004.

FIG. 21 is an example timing diagram showing an illustrative process2100 for transferring currency via the offer processing system accordingto some implementations. As shown in the illustrated example, theprocess 2100 is performed over times T1-T6 by actors, such as a firstuser 2102, the offer processing system 2104, and a second user 2106. Inthis example, the first user 2102 is transferring or sending currency orvalue via the offer processing system 2104 to an account or ledgerassociated with the second user 2106. However, the first user 2102 islocated within the United States that utilized the US dollar as themonetary unit and the second user 2106 is located within the UnitedKingdom that utilizes the Pound as the monetary unit.

In this example, the offer processing system 2104 may be configured topresent the value stored on a user's ledger or account in the monetaryunit that the user is accustomed to using or the monetary unitassociated with a user's current location. Thus, the offer processingsystem 2104 may be configured and/or registered as a currency exchangesystem.

At 2108 and time T1, the first user 2102 may send a currency transferrequest to transfer a portion of the value associated with the user's2102 account or ledger to the second user 2106 via a user deviceassociated with the first user 2102. For example, the first user 2102may be giving a gift to a relative.

At 2110 and time T2, the offer processing system 2104 may receive thecurrency transfer request and, at 2112 and time T3, the offer processingsystem 2104 may determine a currency associated with the first user 2102and a currency associated with the second user 2106. The offerprocessing system 2104 may then determine a substantially real timeconversion rate between the currency of the first user 2102 (e.g., USDollars) and the currency of the second user 2106 (e.g., Pounds).

At 2114 and time T3, the offer processing system 2104 may update theledger or account of the first user 2102 and the second user 2106 basedon the amount of currency to be transferred and the determinedconversion rate. At 2116, 2118, and time T4, the offer processing system2104 may send a notification to a user device associated with the seconduser 2106. The user device may then alert the second user 2106 to thedeposit to the second user's 2106 account or ledger.

In the current example, the offer processing system 2104 may maintainledgers or account balances in a currency associated with a location ofthe users. However, in other examples, the offer processing system 2104may maintain the ledgers or account balances in a jurisdiction freecurrency that may be converted prior to transferring value out of theoffer processing system 2104. In some specific examples, thejurisdiction free currency or offer processing system 2104 currency maybe used as a live currency to make purchases, such as travelarrangements or other in system offers. In other examples, thejurisdiction free currency or offer processing system 2104 currency maybe convertible into various point systems, such as rewards points,customer loyalty points, etc., in lieu of a transfer into live currency.

FIG. 22 is another example timing diagram showing an illustrativeprocess 2200 for transferring currency via the offer processing systemaccording to some implementations. As shown in the illustrated example,the process 2200 is performed over times T1-T8 by actors, such as afirst user 2202, the offer processing system 2204, a merchant ormerchant system 2206, and a financial system 2208. In this example, thefirst user 2202 is transferring or sending currency or value via theoffer processing system 2204 to an account or ledger associated with thefinancial system 2208 as well as paying a balance due to a merchant2206. In this example, the user's 2202 account or ledger with the offerprocessing system 2204 may be maintained in the jurisdiction freecurrency or offer processing system 2204 currency, while the financialsystem 2208 is located within the United States and utilized the USdollar as the monetary unit and the merchant system 2206 is locatedwithin the United Kingdom and utilizes the Pound as the monetary unit.

At 2210, 2212, and time T1, the first user 2102 may send and the offerprocessing system 2204 may receive a request to transfer currency to thefinancial system 2208. For example, the user 2202 may desire to depositfunds into a bank account prior to an automatic payment being withdrawn.

At 2214 and time T2, the offer processing system 2204 may determine acurrency associated with the financial system 2208. For instance, in theillustrated example, the offer processing system 2204 may determine thatthe financial system 2208 operates in US Dollars based on a location ofthe financial system 2208 or the user 2202 within the United States. Insome cases, the user 2202 may designate the currency to use for thetransfer, such as a transfer request for Fifty-Five US Dollars.

At 2216 and time T3, the offer processing system 2204 may determine anamount or value to deduct from the ledger or account of the user 2202based on the currency of the financial system 2208 and the currentexchange rate between the offer processing system currency and, in thisexample, the US Dollar.

At 2218, 2220, and T4, the offer processing system 2204 may send and thefinancial system 2220 may receive transaction data to cause the value oramount of US Dollars to be transferred or deposited into an account atthe financial system 2208. In some cases, at 2222 and T4, the offerprocessing system 2204 may also send a notification that is received ata user device associated with the user 2202 that the amount has beentransferred and, in some cases, a balance remaining on the user's 2202ledger or account.

At 2224, 2226, and time T5, the first user 2102 may send and the offerprocessing system 2204 may receive a request to transfer currency to themerchant system 2206. For example, the user 2102 may desire to pay abill or balance due to the merchant 2206.

At 2228 and time T6, the offer processing system 2204 may determine acurrency associated with the merchant system 2206. For instance, in theillustrated example, the offer processing system 2204 may determine thatthe merchant system 2206 operates in Pounds based on a location of themerchant system 2206. In some cases, the user 2202 may designate thecurrency to use for the transfer, such as a transfer request for OneHundred Pounds.

At 2230 and time T7, the offer processing system 2204 may determine anamount or value to deduct from the ledger or account of the user 2202based on the currency of the merchant system 2206 and the currentexchange rate between the offer processing system currency and, in thisexample, the Pound.

At 2232, 2234, and T8, the offer processing system 2204 may send and themerchant system 2206 may receive transaction data to cause the value oramount of Pounds to be transferred or deposited into an accountassociated with the merchant system 2206. In some cases, at 2236 and T8,the offer processing system 2204 may also send a notification that isreceived at a user device associated with the user 2202 that the amounthas been transferred and, in some cases, a balance remaining on theuser's 2202 ledger or account.

While actions associated with the FIGS. 16-22 above are shown atparticular times T1-T8 in a particular order, it should be understoodthat in some cases a period of item between each time T1-T8 may vary andthat actions associated with a time T1-T8 may be performed over a lengthof time or at substantially the same time.

FIGS. 23-27 are flow diagrams illustrating example processes associatedwith an offer processing system according to some implementations. Theprocesses are illustrated as a collection of blocks in a logical flowdiagram, which represent a sequence of operations, some or all of whichcan be implemented in hardware, software or a combination thereof. Inthe context of software, the blocks represent computer-executableinstructions stored on one or more computer-readable media that, whichwhen executed by one or more processors, perform the recited operations.Generally, computer-executable instructions include routines, programs,objects, components, encryption, deciphering, compressing, recording,data structures and the like that perform particular functions orimplement particular abstract data types.

The order in which the operations are described should not be construedas a limitation. Any number of the described blocks can be combined inany order and/or in parallel to implement the process, or alternativeprocesses, and not all of the blocks need be executed. For discussionpurposes, the processes herein are described with reference to theframeworks, architectures and environments described in the examplesherein, although the processes may be implemented in a wide variety ofother frameworks, architectures or environments.

FIG. 23 is example flow diagram showing another illustrative process2300 for redeeming offers according to some implementations. Forinstance, an offer processing system may be configured to monitortransaction data associated with purchases of one or more users and todetermine if each purchase made by one or more users using a registeredpayment credential qualifies for an offer. When the offer processingsystem determines that a purchase does qualify for an offer, the offerprocessing system may redeem the offer on behalf of the user and alertthe user to the savings.

At 2302, a user may purchase an item at a point of sale system. Forexample, the user may utilize payment credentials stored with the offerprocessing system to make a purchase that qualifies for one or moreoffers, cash back deals, or savings.

At 2304, the payment processing system may receive transaction dataassociated with the purchase of the user from the point of sale system.And, at 2306, the third party payment processing system may provide thetransaction data to the offer processing system during the pendency ofthe transaction or prior to final approval of the transaction.

At 2308, the offer processing system may identify one or more offersassociated with the transaction data. For example, the offer processingsystem may determine that the transaction was at a particular merchantrunning a cash back offer for purchases greater than $35 and that thepurchase was for $40. In other cases, such as when SKU data is availablein addition to the transaction data or in lieu of the transaction data,the offer processing system may determine that the transaction includesthe purchase of an item that a distributor of the item has a currentcash back offer on.

At 2310, the offer processing system may identify a user associated withthe transaction. In this example, the offer processing system mayidentify the user based on matching the payment credentials used to makethe purchase at the point of sale system as belonging to a particularuser.

At 2312, the offer processing system may redeem the offer. For example,offer processing system may redeem the offer with a third party couponsettlement company. In another example, the offer processing system mayredeem the offer directly with a merchant or distributor.

At 2314, the offer processing system may update the ledger associatedwith the user. For example, the offer processing system may determinewhat portion of the value redeemed is to be credited to the user andthen update or credit the user's ledger with the portion of the value.In some cases, other portions of the value may be charged as aprocessing fee or distributed to other users of the system.

At 2316, the offer processing system may send a notification as to thevalue that is credited to the user's ledger to a user device associatedwith the user. At 2318, the user device may receive the notificationfrom the offer processing system and, at 2320, the user device may alertthe user to the credit. For instance, the user device may vibrate, emita sound, generate a visual indication, etc. to alert the user to thecredit.

FIG. 24 is example flow diagram showing another illustrative process2400 for sharing offers according to some implementations. In thecurrent example, a first user is sharing an offer with a second user.For instance, the first user may have received a notification associatedwith the offer indicating that the offer applied to a recent purchase ofthe first user. The first user may then determine that the second usermay be interested in the offer.

At 2402, the first user may cause a user device to indicate that thefirst user desires to share the offer with the second user. The userdevice may transmit share instructions to the offer processing system,such that the offer processing system may facilitate the sharing of theoffer.

At 2404, the offer processing system may receive the share instructionsfrom the first user's device and update a chain of title associated withan instance of the offer. The chain of title may be used to track thesharing of the offer in order to credit individual users when a userrecorded in the chain of title completes a purchase which meets orexceeds the criteria of the offer. In one particular example, the offerprocessing system may update a hash code associated with the instance ofthe offer to track the chain of title data in a way that is difficult tofake.

At 2406, the offer processing system may send the offer instance to thesecond user. For example, the offer processing system may send anotification or cause a user device associated with the second user todisplay the offer when the second user logs into the second user'saccount. At 2408, the second user's device may receive the notificationand the second user may be alerted to the offer.

At 2410, the second user may make a purchase that meets or exceeds thecriteria of the offer. For example, the second user may purchase theitem being highlighted in the offer or complete a transaction at aparticular merchant.

At 2412, the offer processing system may receive transaction dataassociated with the purchase. For instance, the offer processing systemmay receive the transaction data from a third party payment processingsystem. In another instance, the offer processing system may receive thetransaction data and/or SKU data from a point of sale device or system.In some particular instances, the offer processing system may receivethe transaction data from both a third party payment processing systemand a third party point of sale system.

At 2414, the offer processing system may detect that the transactiondata meets or exceeds the requirements of the offer. For example, theoffer processing system may compare the transaction data to variousmerchant that have active offers and if a match is determined, comparethe criteria of the offer to the transaction data to determine if anamount meets or exceeds an amount associated with the offer. In othercases, the offer processing system may compare SKU data with itemidentifiers that have corresponding active offers.

At 2416, the offer processing system may determine that the transactionis associated with the second user. For example, the offer processingsystem may detect the stored payment credentials are being used toprocess the transaction represented by the transaction data.

At 2418, the offer processing system may determine the chain of titleassociated with the offer instance or if an offer instance was sharedwith or by the second user. For example, the offer processing system maydetermine that the first user shared the offer with the second userprior to the second user completing the purchase that met or exceededthe criteria of the offer.

At 2420, the offer processing system may update a ledger associated withthe first user and a ledger associated with the second user. Forinstance, once the offer processing system determines that the offer wasshared by the first user with the second user and that the chain oftitle is valid, the offer processing system may allocate a portion ofthe value of the offer to the first user and the remainder of the valueto the second user.

At 2422, the offer processing system may send notifications to the firstuser and the second user to alert the users that a portion of the valueof the offer has been credited to the first user's account or ledger andthat the remainder of the value has been credited to the second user'saccount or ledger.

At 2424, the device associated with the first user may receive thenotification and, at 2426, the device associated with the first user mayalert the first user to the notification. Similarly, at 2428 the deviceassociated with the second user may receive the notification and, at2430, the device associated with the second user may alert the seconduser to the notification.

FIG. 25 is example flow diagram showing another illustrative process2500 for generating offers according to some implementations. Forexample, public offers or discounts may be detected or identified by theoffer processing system. In other examples, merchants, distributors,marketplaces may utilize the offer processing system or a merchantplatform module of the offer processing system to generate offers thatare private to the users of the offer processing system.

At 2502, the offer processing system may receive offer data from thirdparty merchants. For example, the merchant may generate or create offersfor use by the offer processing system in order to encourage the usersof the offer processing system to make a purchase with the merchant. Insome particular examples, the offer processing system may generatecampaigns including multiple offers or changing offers based onthresholds, such as date, time, number of times an offer is redeemed,revenue generated, total user savings, etc.

At 2504, the offer processing system may identify offers open to thepublic. For example, the offer processing system may import offerslisted at various coupon sites, at merchant sites, marketplace sites,etc. In one particular example, the offer processing system may includeweb-crawlers that may parse or search the Internet® for active offers.

At 2506, the offer processing system may identify offers associated witha marketplace. For example, the offer processing system may importoffers that are available for shopping through marketplace sites, suchas Etsy.

At 2508, the offer processing system may identify or request offersavailable at a third party coupon settlement company. For example, theoffer processing system may import offers that are redeemable at thethird party coupon settlement company or may request a list of offersredeemable via the third party coupon settlement company.

At 2510, the offer processing system may aggregate the offers. Forinstance, the offer processing system may combine offers (e.g., offersvalid on a particular item via the distributor and a particularmerchant). The offer processing system may also remove duplicate offers(e.g., offers identified from public websites that mirror offersgenerated by a merchant or distributor with the offer processingsystem).

At 2512, the offer processing system may receive transaction dataassociated with the purchase. For instance, the offer processing systemmay receive the transaction data from a third party payment processingsystem. In another instance, the offer processing system may receive thetransaction data and/or SKU data from a point of sale device or system.In some particular instances, the offer processing system may receivethe transaction data from both a third party payment processing systemand a third party point of sale system.

At 2514, the offer processing system may determine that at least oneoffer applies to the transaction data. For instance, the offerprocessing system may detect that the transaction data meets or exceedsthe requirements of the offer. In one particular example, the offerprocessing system may compare the transaction data to various merchantidentifiers that have active offers and if a match is determined,compare the criteria of the offer to the transaction data to determineif an amount is met or exceeded. In other cases, the offer processingsystem may compare SKU data with item identifiers that havecorresponding active offers.

At 2516, the offer processing system may determine that the transactionis associated with a user. For example, the offer processing system maydetect the stored payment credentials are being used to process thetransaction represented by the transaction data.

At 2518, the offer processing system may request settlement of the offerfrom a third party coupon settlement system. For example, the offerprocessing system may redeem the value or request the value of the offerfrom the third party coupon settlement system.

At 2520, the offer processing system may update a ledger associated withthe user and send notifications to the user to alert the users that thevalue of the offer has been credited to the user's account or ledger.

FIG. 26 is example flow diagram showing another illustrative process2600 for transferring currency according to some implementations. Forexample, the offer processing system may maintain the ledger or useraccounts in a jurisdiction free or offer processing system currency.Thus, the offer processing system may convert the offer processingsystem currency via an exchange module into a corresponding value in acurrency of an entity, user, or business when the currency is beingtransferred to a third party outside of the offer processing system.

At 2602, the offer processing system may receive a request to transfercurrency to an entity. For example, the offer processing system mayreceive a request from a user to transfer currency to another individualas a gift, to a business, for instance, pay a bill, to a financialinstitute (e.g., a checking or savings account of the user), etc.

At 2604, the offer processing system may determine a currency associatedwith the entity. For instance, the offer processing system may determinethat the financial system operates in US Dollars based on a location ofthe financial system or the user being within the United States. In somecases, the user may designate the currency to use for the transfer, suchas a transfer request for Fifty-Five US Dollars. In other cases, theoffer processing system may determine the currency based on a preferredcurrency of the entity. for instance, the offer processing system mayallow entities to provide or suggest a preferred currency to use intransactions associated with the entity.

At 2606, the offer processing system may update a ledger associated withthe user and send notifications to the user to alert the users to thevalue being transferred to the entity. For example, once the entitycurrency is determined the offer processing system may calculate anamount of offer processing system currency to deduct from the user'saccount or ledger.

At 2608, the offer processing system may transfer the currency to theentity. for example, the offer processing system may utilize a vault orsecure electronic transfer protocol to transfer the currency to theentity.

FIG. 27 is example flow diagram showing another illustrative process2700 for generating travel or discount based offers according to someimplementations. In some cases, such as travel inventory, items may beoffered at a discount or at a wholesale price to special individuals orentities. In these cases, the offer processing system may be configuredto purchase items or catalogue the items in order to create cash backoffers based on the discount or savings due to the whole sale price.Thus, the savings may be passed on to users of the offer processingsystem whom may otherwise not be able to access the wholesale ordiscounted goods.

At 2702, the offer processing system may identify wholesale ordiscounted items. For example, the offer processing system may accesstravel wholesale systems to catalog hotel rooms or airline seats thatare available for purchase at the wholesale price.

At 2704, the offer processing system may determine the competitivepricing for the item. For instance, the offer processing system maydetermine the pricing of the item from other discount sales systems. Inone particular example, the offer pricing system may determine thepricing of travel aggregator or discount travel systems to determine thecompetitive pricing.

At 2706, the offer processing system may generate an offer for the item.For example, the offer processing system may generate the offer based onthe wholesale or discounted price for the item and the competitivepricing. In one particular instance, the offer processing system maygenerate an offer equal to the difference between the wholesale ordiscount price and the lowest price offered by a competitor. In othercases, the offer processing system may generate an offer equal to apercentage of the difference between the wholesale or discount price andthe lowest price offered by a competitor.

At 2708, the offer processing system may receive transaction data. Forexample, the offer processing system may receive the transaction datafrom a third party payment processing system or a third party point ofsale system. In some cases, the transaction data may also include SKUdata. In one pericarp, example, the offer processing system may receivethe transaction data from a user device, such as when the offer ispurchasable through a client side application associated with the offerprocessing system.

At 2710, the offer processing system may identify that the offer isassociated with the transaction data. For example, the offer processingsystem may determine that a user selected to purchase the wholesale ordiscounted item via the offer processing system by clicking on selectingthe offer.

At 2712, the offer processing system may identify a user associated withthe transaction. In this example, the offer processing system mayidentify the user based on a user account or user device utilized tomake the purchase via the offer processing system.

At 2714, the offer processing system may update a ledger associated withthe user. For example, the offer processing system may redeem the offerby purchasing the item from the wholesale or discounted location andthen credit the user's account or ledger with the price difference.

At 2716, the offer processing system may send a notification as to thevalue that is credited to the user's ledger or account to a user deviceassociated with the user. The user device may receive the notificationfrom the offer processing system and, alert the user to the credit. Forinstance, the user device may vibrate, emit a sound, generate a visualindication, etc. to alert the user to the credit.

FIG. 28 illustrates an example architecture of one or more serversassociated with an offer processing system 2800 according to someimplementations. The servers, which host the offer processing system2800 collectively comprise processing resources, as represented byprocessors 2802, and computer-readable storage media 2804. Thecomputer-readable storage media 2804 may include volatile andnonvolatile memory, removable and non-removable media implemented in anymethod or technology for storage of information, such ascomputer-readable instructions, data structures, program modules, orother data. Such memory includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,RAID storage systems, or any other medium which can be used to store thedesired information and which can be accessed by a computing device.

The servers may also include one or more communication interfaces 2806,which may support both wired and wireless connection to variousnetworks, such as cellular networks, radio (e.g., radio-frequencyidentification (RFID)), WiFi networks, short-range or near-fieldnetworks (e.g., Bluetooth®), infrared signals, local area networks, widearea networks, the Internet, and so forth. For example, thecommunication interfaces 2806 may allow the offer processing system 2800to receive transaction data, user communications, and/or offer data fromuser devices and third party systems. In some cases, a co-locatedmanagement system may act as a proxy or additional tier for acloud-based management system.

Several modules such as instructions, data stores, and so forth may bestored within the computer-readable storage media 2804 and configured toexecute on the processors 2802. For example, a merchant platform module2808, a merchant dashboard module 2810, an offer identification module2812, an offer generation module 2814, an offer selection module 2816, avault module 2818, a transaction processing module 2820, a chain oftitle module 2822, a ledger module 2824, a notification module 2826, acurrency exchange module 2828, a user dashboard module 2830, as well asother modules 2832. In some implementations, the computer-readable media2804 may store data, such as account data 2834, transaction data 2836,travel data 2838, user data 2840, ledger data 2842, and offer data 2844,as well as other data.

The merchant platform module 2808 may allow merchants, marketplaces,distributors, or other entities or individuals to create offers and/oroffer campaigns with the offer processing system 2800. For example, themerchant or marketplace may utilize the merchant platform module 2808 tocreate cash back offers associated with shopping at particular retailestablishments or online venues. Similarly, the distributors may createoffers associated with purchasing a particular item, unit, or serviceoffered by the distributor regardless of the merchant or marketplaceutilized to purchase the item, unit, or service.

The merchant dashboard module 2810 may allow the merchant, marketplace,coupon system, distributor or other entity or individual to track theeffectiveness of an offer, such as a redemption rate, a sharing rate, aview or impression rate, etc. In some cases, the merchant dashboardmodule 2810 may convert the redemption rate into a revenue versusexpense metric using the offer data 2844, user data 2840, andtransaction data 2836 received from third party payment processingsystems and/or third party point of sale systems. In some cases, themerchant dashboard module 2810 may allow the merchant, marketplace,coupon system, distributor or other entity or individual to trackpurchases across payment credentials even from the same user. Forinstance, if a user redeems the same offer at the same venue bututilized two different payment credentials (e.g., a debit card and acredit card), the offer processing system 2800 may aggregate thetransaction data 2836 and present to the merchant, marketplace, couponsystem, distributor or other entity or individual viewing results of anoffer the fact that the same user made two purchases associated with anoffer using two different payment credentials.

The offer identification module 2812 may be configured to search andlocate the offer data 2844 associated with current valid offers providedby the sources. For example, the offer identification module 2812 mayidentify offers on various items, retail locations, online venues, etc.by searching networks for the offer data 2844. For instance, in oneparticular example, the offer identification module 2812 may locate andcollect offer data 2844 associated with offers posted on the Internet®.

The offer generation module 2814 may be configured to generate offersbased on the offer data 2844 collected by the offer identificationmodule 2812. For example, the offer identification module 2812 mayidentify discount or whole sales goods (e.g., via a travel wholesalersystem). The offer generation module 2814 may convert the discountedprice or whole sale price of the goods into an offer redeemable byusers. In one particular implementation, the offer generation module2814 may be configured to purchase discounted items, units, inventory,or services and to generate offers to purchase the discounted items,units, inventory, or services via the offer processing system 2800.

In one particular example, the offer identification module 2812 mayidentify the discounted travel inventory or wholesale travel inventoryas well as competitive pricing associated with the travel inventory. Theoffer generation module 2814 may then generate an offer based in part ona difference between the discounted or wholesale price and thecompetitive pricing. For example, the offer may include a cash backoffer of a percentage of the difference.

The offer selection module 2816 may select offers to send to user basedat least in part on the offer data 2844, account data 2834, and/or userdata 2840. For example, the user data 2840 may include location datareceived from one or more of the user devices associated with individualusers. The offer selection module 2816 may select and send offers withina threshold distance of the corresponding user device. In other cases,the offer selection module 2816 may select offers to send to the usersbased on past buying history, user selected interests, etc.

The vault module 2818 may include a secure level or security to allowthe offer processing system 2800 to receive the confidential transactiondata 2836 from the third party payment processing systems and/or thethird party point of sale systems.

The transaction processing module 2820 may be configured to identify auser associated with a transaction and/or and offer associated with thetransaction. For instance, the user may be identified based the paymentcredentials associated with the transaction. The offer may be identifiedbased on the merchant identifier or SKU data associated with thetransaction.

The chain of title module 2822 may be configured to determine if aninstance of an offer was shared with a user associated with atransaction and to determine each individual that shared the offer orthe chain of individuals that shared the offer. In some cases, the chainof title module 2822 may also determine that the offer is still validbased on, for instance, an initiating node of the chain of title havinga valid time stamp or hash code.

The ledger module 2824 may be configured to maintain the ledgers oraccounts associated with each of the users of the offer processingsystem 2800. For example, the ledger module 2824 may be configured todebit and credit the ledger of each user as offers are redeemed onbehalf of the user and as the user transferred currency to otherinstitutions.

The notification module 2826 may be configured to provide notificationsto the user devices. For example, the notification module 2826 may sendoffers that may be of interest to the users, information related toredeemed offers, completion of actions (e.g., currency transfers), etc.

The currency exchange module 2828 may be configured to determine acurrency associated with an individual or entity that funds are beingtransferred to. For instance, the currency exchange module 2828 mayconvert currency associated with a user's ledger from a currencyassociated with the user (e.g., US Dollars) or an offer processingsystem currency into a currency associated with a third party prior todebiting the user's ledger for the withdrawal. In this manner, the offerprocessing system 2800 may improve conventional exchange systems byconverting the currency prior to initiating a transfer, thereby savingprocessing resources associated with a monetary exchange.

The user dashboard module 2830 may allow the user to view offers, searchoffers, redeem offers, make purchases (e.g., travel inventorypurchases), transfer currency, add payment credentials, view socialsharing and redeeming of offers, among others.

FIG. 29 illustrates example components of one or more user devices 2900hosting a client side application associated with the offer processingsystem according to some implementations. The devices 2900 may host orimplement an application or app that allows the user to interact withthe offer processing system described herein. The device 2900 mayinclude one or more processors 2902, and computer-readable storage media2904 as well as commination interfaces 2906, sensors 2908, andinput/output interfaces 2910.

The communication interfaces 2906 may support both wired and wirelessconnection to various networks, such as cellular networks, radio (e.g.,radio-frequency identification (RFID)), WiFi networks, short-range ornear-field networks (e.g., Bluetooth®), infrared signals, local areanetworks, wide area networks, the Internet, and so forth. For example,the communication interfaces 2906 may allow the device 2900 to receivenotifications from the offer processing system.

The sensors 2908 may be used to monitor position and movement of theuser device 2900. For example, the sensors may include motion sensors(e.g., gyroscopes and accelerometers) and/or position sensors (e.g.,Global Position System (GPS) or other satellite receivers based locationtracking systems). In some case, the sensors 2908 may include systemsfor tracking movement based on wireless signals, such as the nearestcellular tower or currently connected tower.

The input/output interfaces 2910 may include one or more outputcomponents, such as a display or touch screen, and one or more inputcomponents, such as keyboards, keypads, joysticks, a mouse, a touchscreen, touch pad, drawing pad, or control buttons. In someimplementations, the output components and input components are combinedin a single interface to provide a touch-sensitive display, or touchscreen display. For instance, in the illustrated example, theinput/output interfaces 2910 include one or more displays for presentinginformation, such as electronic content items, to a user, one or moreinput sensors for accepting input resulting from contact and/orapplication of incident force, such as a user finger or stylus pressingupon one of the sensor.

The computer-readable storage media 2904 may include volatile andnonvolatile memory, removable and non-removable media implemented in anymethod or technology for storage of information, such ascomputer-readable instructions, data structures, program modules, orother data. Such memory includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,RAID storage systems, or any other medium which can be used to store thedesired information and which can be accessed by a computing device.

Several modules such as instruction, data stores, and so forth may bestored within the computer-readable storage media 2904 and configured toexecute on the processors 2902. For example, the computer-readable media2904 may store a social module 2912 to allow users to share offers andview social activity (e.g., total redeemed value on shared offers). Thecomputer-readable media 2904 may also store a sensor module 2914 toprocess the sensor data generated by the sensors 2908 and to send thedata to the offer processing system via the communication interfaces2906. In some cases, the computer-readable media 2904 may store an offersearch module 2916 to allow the user to search for offers on particularitems, merchants, venues, etc. The offer processing system 2900 may alsostore a transaction module 2918 to allow the user to purchase items,units, or inventory via the offer processing system (e.g., discountedtravel inventory). The computer-readable media 2904 may also store analert module 2920 to alert the user to notifications received from theoffer processing system and to credit earned when the offer processingsystem redeems offers on the user's behalf. In addition to the offerprocessing modules, the computer-readable media 2904 may store othermodules 2922. In some implementations, the computer-readable media 2904may store data, such as user data 2924, account data 2936, and socialdata 2928.

FIG. 30 is an illustrative example home interface 3000 of a client sideapplication of the offer processing system according to someimplementations. In the current illustration, the application ispresenting on a display of a user device, a currency balance 3002 oramount of the user's ledger or account. For instance, the balance 3002may be accumulated by the offer processing system redeeming offers onthe user's behalf and crediting the value or a portion of the valueredeemed to the user.

The application is also presenting on a display of a user device, atotal social currency balance 3004. In this example, the social currencybalance 3004 may be a total value of redeemed offers that wereassociated with an instance of an offer shared by the user. Thus, if theuser shared an instance of an offer with a second user and a third userand both the second and third user redeemed the offer, the valuereceived by the second and third user may be added to the socialcurrency balance 3004. The home interface 3000 may also display a listof notifications 3006 received from the offer processing system. In thisexample, the notifications 3006 include notices that friends orconnections of the user earned value or currency based on offers withMerchant A and Merchant B. In this instance, the user may select theoffers associated with Merchant A or Merchant B to learn more.

FIG. 31 is an illustrative example user interface 3100 for managingpayment credentials of a client side application of the offer processingsystem according to some implementations. In this example, the user haslinked two payment credentials 3102 and 3104 (e.g., two credit cards) tothe offer processing system. Thus, if the user purchases items using thepayment credentials 3102 or 3104, the offer processing system may locateand redeem offers on the user's behalf. In the current example, the useris also able to add additional payment credentials using button 3106.

FIG. 32 is an illustrative example user interface 3200 for enteringpayment credentials into the offer processing system according to someimplementations. For instance, in the illustrated example, the user mayselect a payment type 3202 or 3204 (e.g., a credit card, debit card,bank account, routing number, etc.). The user may also be able to enterinformation, such as billing information, associated with the paymentcredentials.

FIG. 33 is an illustrative example wallet interface 3300 of a clientside application of the offer processing system according to someimplementations. In the illustrated example, the user may transfercurrency 3302 or donate currency 3304 to various organizations,individuals, or entities. For example, the user may transfer a portionof the balance 3306 of the user's wallet or ledger to other individualsor entities. In some cases, such as the current example, the applicationmay also cause the display to present a list, generally indicated by3308, of previous or current transactions performed using theapplication.

FIG. 34 is an illustrative example offer search interface 3400 of aclient side application of the offer processing system according to someimplementations. In the current example, the user may be utilizing theapplication to search for available offers. In some cases, the offersreturned by the offer processing system may be sorted based on variousconditions 3402. For instance, the offers may be sorted based on userratings or system ratings, distance from the user's location, biggestdiscount or most currency back, price either high to low or low to high,alphabetical or others.

FIG. 35 is an illustrative example offer search interface 3500 of aclient side application of the offer processing system according to someimplementations. In the current example, the user may be able to searchfor offers based on time or date. For instance, the user may select daysfrom a calendar 3502 for which the user desires to view offers. Forinstance, in the case of travel inventory the user may desire to view,discounted or wholesale travel offers within a time period associatedwith the user's trip. In some cases, the calendar 3502 may be utilizedas a booking tool such as for hotel rooms for a period of time.

FIG. 36 is an illustrative example offer search interface 3600 of aclient side application of the offer processing system according to someimplementations. In the current example, the user may have performed asearch based on a distance from a current location of the user or theuser device. Once the user requests the search results, the client sideapplication may cause the user device to display the results in a list3602 based on distance from the user device.

FIG. 37 is an illustrative example offer search interface 3700 of aclient side application of the offer processing system according to someimplementations. In the current example, the user may have performed asearch based on a distance from a current location of the user or theuser device. In this case, the client side application may cause theuser device to display the results in a map 3702. In some cases, theposition of the map 3702 may be based on a known location of the user orthe user device. In some cases, the offer presented, such as offers3704, may be within a threshold range of the user. In some cases, therange may be changed by the user by zooming in and out of the map 3702.

In the illustrated example, a selected offer 3706 may be presented inmore detail within an offer window 3708. Thus, if the user selectsanother offer 3704 on the map 3702, the offer window 3708 may presentdetails associated with the newly selected offer.

FIG. 38 is an illustrative example offer search interface 3800 of aclient side application of the offer processing system according to someimplementations. In the current example, the user may have performed asearch based on a distance from a desired location of the user or theuser device. For instance, the user may desire to search for hotel roomsin or around a desired location of the user's trip. In this case, theclient side application may cause the user device to display the resultsin a map 3802. In some cases, the position of the map 3802 may be basedon a location selected by the user. In some cases, the offer presented,such as offers 3804, may be within a threshold range of the locationselected by the user. In some cases, the range may be changed by theuser by zooming in and out of the map 3802.

In the illustrated example, a selected offer 3808 may be presented inmore detail within an offer window 3810. Thus, if the user selectsanother offer 3806 on the map 3802, the offer window 3810 may presentdetails associated with the newly selected offer.

FIG. 39 is an illustrative example travel inventory offer interface 3900of a client side application of the offer processing system according tosome implementations. In the current example, the user may be viewingavailable travel inventory offers, such as travel inventory offer 3902and 3904. In this example, the offers may be generated by the offerprocessing system and based on a difference or percentage of adifference between the competitive pricing of the travel inventory,generally indicated by 3906 and 3908, and a price the travel inventoryis purchased at or purchasable for based on a wholesale price.

FIG. 40 is an illustrative example travel inventory offer interface 4000of a client side application of the offer processing system according tosome implementations. In the current example, the user may be viewingavailable travel inventory offers, such as travel inventory offer 4002and 4004. In this example, the user may be renting a vehicle and thatthe offer processing system has access to vehicle rentals at adiscounted or wholesale price. Thus, the offer processing system maygenerate offers based on a difference between competitive pricing andthe discounted or wholesale price.

FIG. 41 is an illustrative example donation interface 4100 of a clientside application of the offer processing system according to someimplementations. in this example, the user may decide to donate aportion of the user's balance 4102. In this example, the user may selectbetween charities, such as charity 4104 and 4106. The user may alsoselect or enter an amount of the balance 4102 to donate using a userinput area 4108.

FIG. 42 is an illustrative example user interface 4200 of a client sideapplication of the offer processing system for transferring currency toother entities according to some implementations. In the currentexample, the user may select entities and cause or allow the offerprocessing system to transfer a portion of the value of the balance 4202between selected entities. In this example, the user may select from alist 4204 of entities to pay bills and transfer currency. In some cases,the user may be able to transfer funds stored with the entity into theoffer processing system.

FIG. 43 is an illustrative example donation interface 4300 of a clientside application of the offer processing system according to someimplementations. For instance, after an offer has been redeemed by theoffer processing system, the offer processing system may present to theuser an option to donate a portion of the redeemed value or a portion ofthe user's balance 4302. In this example, the offer processing systemmay provide a list 4304 including various selectable options to donate.For instance, in the current example, the user has selected to donate$25 to Charity A.

FIG. 44 is an illustrative example merchant interface 4400 associatedwith an offer processing system according to some implementations. Inthe illustrated example, the merchant, distributor, marketplace, orother entity may be viewing a dashboard 4402. In this case, the merchantmay be able to view the total sales activity, for instance, over time ina sales activity window 4404. The merchant may be able to view the totalsales activity based on demographic information, such as location,gender, and age, among others, in a demographic window 4406.

In some cases, the dashboard 4402 may present data related to the topperforming offers, such as offers 4408, 4410, 4412, and 4414, in anoffer performance window 4416. In the illustrated example, the offerdata may be presented as both a graph 4418 as well as in a more detailedoffer via a per offer view, such as offer views 4408, 4410, 4412, and4414.

The merchant may be able to view social data in a social window 4420.For instance, in the illustrated example, the social data is presentedas a graph of shares over time per offer. The offer processing systemmay also present to the merchant via the dashboard 4402 data related toa number of transaction during a period of time, number or percentage ofnew customers during the period of time, average purchase price of atransaction during the period of time, and the number of users on theoffer processing system that may be customers of the merchant.

FIG. 45 is another illustrative example merchant interface 4500associated with an offer processing system according to someimplementations. In the current example, the merchant may be viewing anoffer detail view 4502. In this example, the offer processing system maypresent to the user analytics associated with revenue generated from anoffer, generally indicated by 4504, in comparison with costs associatedwith the offer, generally indicated by 4506. For instance, the offerprocessing system may present revenue as the amount of currency earnedby the merchant from offer processing system users against the costs orthe amount of value redeemed by the offer processing system on behalf ofthe users of the offer processing system.

FIG. 46 is yet another illustrative example merchant interface 4600associated with an offer processing system according to someimplementations. For instance, the offer processing system may providethe merchant with analytics associated with the social sharing or amountof social activity associated with an offer via a social activity view4602. In these instances, the offer processing system may present datarelated to a total amount of shares per offer over a period of time in asocial activity window 4604. The social activity view 4602 may alsoinclude a top referrer or top sharer window 4606 to highlight theindividual users that share the offers of the merchant to the greatestextent. In some cases, the social activity view 4602 may also include anew user and return user window 4608 to illustrate to the merchant howmany return customers redeemed offers compared with the number of newcustomers that redeemed offers. In one particular example, the socialactivity view 4602 may include a results window 4610 to present to themerchant the results of the merchant's offers over a predefined periodof time, such as 30 days.

Although the subject matter has been described in language specific tostructural features, it is to be understood that the subject matterdefined in the appended claims is not necessarily limited to thespecific features described. Rather, the specific features are disclosedas illustrative forms of implementing the claims.

What is claimed is:
 1. A system comprising: one or more communicationinterfaces; one or more processors; and computer-readable storage mediastoring computer-executable instructions, which when executed by the oneor more processors cause the one or more processors to: receive, via theone or more communication interfaces and via a vault system, transactiondata, in tokenized form, from the third party payment processing systemfor a purchase by a user; determine the user associated with thetransaction data; determine that the purchase represented by thetransaction data meets or exceeds a criteria of an offer; cause the oneor more communication interfaces to redeem the offer with a third partycoupon settlement system; receive a currency value associated with theoffer from the third party coupon settlement system; and credit aportion of the currency value in a jurisdiction independent currency toan account associated with the user and separate from a payment accountassociated with the payment credential.
 2. The system as recited inclaim 1, wherein the computer-readable storage media stores additionalcomputer-executable instructions, which when executed by the one or moreprocessors cause the one or more processors to: receive paymentcredentials from a user device associated with the user; and whereindetermining the user is associated with the transaction data is based atleast in part on determining the payment credentials are associated withthe transaction data.
 3. The system as recited in claim 1, wherein thecomputer-readable storage media stores additional computer-executableinstructions, which when executed by the one or more processors causethe one or more processors to: send a notification to a user device, thenotification to cause the user device to alert the user to the portionof the currency value credited to the user account.
 4. The system asrecited in claim 1, wherein the offer is a cash back offer.
 5. Thesystem as recited in claim 1, wherein the offer is associated with atleast one of: a merchant; a distributor; an item; a unit; a service; ora marketplace.
 6. The system as recited in claim 1, wherein thecomputer-readable storage media stores additional computer-executableinstructions, which when executed by the one or more processors causethe one or more processors to: receive, via the one or morecommunication interfaces, stock keeping unit data from a third partypoint of sale device; determine that the user associated with the stockkeeping unit data; determine that the stock keeping unit data meets orexceeds a criteria of a second offer; causing the one or morecommunication interfaces to redeem the second offer; receive secondvalue associated with the second offer; and credit a portion of thesecond value to the account associated with the user.
 7. The system asrecited in claim 6, wherein the second offer is associated with an itemidentifiable in the stock keeping unit data.
 8. The system as recited inclaim 1, wherein the computer-readable storage media stores additionalcomputer-executable instructions, which when executed by the one or moreprocessors cause the one or more processors to: transferring the portionof the currency value from the account to a third party financialsystem.
 9. A method comprising: receiving transaction data via a vaultsystem and in tokenized form from the third party system for a purchaseby a first user; determining the first user from a plurality of usersassociated with the transaction data; determining that the purchaserepresented by the transaction data meets or exceeds a criteria of anoffer; redeeming the offer with a third party coupon settlement system;receiving a currency value associated with the offer from the thirdparty coupon settlement system; and crediting a portion of the currencyvalue in a jurisdiction independent currency to a ledger associated withthe first user and separate from a payment account associated with thepayment credential.
 10. The method as recited in claim 9, wherein thethird party system is at least one of a third party payment processingsystem or a third party point of sale system.
 11. The method as recitedin claim 9, wherein the transaction data includes stock keeping unitdata.
 12. The method as recited in claim 9, further comprising:receiving second transaction data from a second third party system;determining a second user from the plurality of users associated withthe second transaction data; determining that the second transactiondata meets or exceeds a criteria of a second offer; redeeming the secondoffer with the third party coupon settlement system; receiving secondvalue associated with the second offer from the third party couponsettlement system; and crediting a portion of the second value to aledger associated with the second user.
 13. The method as recited inclaim 12, wherein the criteria of the offer and criteria of the secondoffer are different.
 14. The method as recited in claim 12, wherein thecriteria of the offer and the criteria of the second offer areidentical.
 15. One or more non-transitory computer-readable media havingcomputer-executable instructions that, when executed by one or moreprocessors, cause the one or more processors to perform operations to:receive, via one or more communication interfaces via a vault, stockkeeping unit data, in tokenized form for a purchase by a user from athird party point of sale system; determine the user associated with thestock keeping unit data; determine that the purchase associated with thestock keeping unit data includes an item that is associated with anoffer; redeem the offer with a third party coupon settlement system;receive a currency value associated with the offer from the third partycoupon settlement system; and credit a portion of the currency value ina jurisdiction independent currency to an account associated with theuser and separate from a payment account associated with the paymentcredential.
 16. The one or more computer-readable media as recited inclaim 15, having additional computer-executable instructions that, whenexecuted by one or more processors, cause the one or more processors toperform operations to: receive second stock keeping unit data from thethird party point of sale system; determine the user is associated withthe second stock keeping unit data; determine that the second stockkeeping unit data includes a second item that is associated with asecond offer; redeem the second offer with a second third party couponsettlement system; receive second value associated with the second offerfrom the second third party coupon settlement system; and credit aportion of the second value to the account associated with the user. 17.The one or more computer-readable media as recited in claim 16, havingadditional computer-executable instructions that, when executed by oneor more processors, cause the one or more processors to performoperations to: storing the stock keeping unit data and the second stockkeeping unit data as data related to the user.
 18. The one or morecomputer-readable media as recited in claim 15, having additionalcomputer-executable instructions that, when executed by one or moreprocessors, cause the one or more processors to perform operations to:receive transaction data from the third party payment processing system;determine the user is associated with the transaction data; determinethat the transaction data is associated with a merchant that isassociated with a second offer; redeem the second offer with a secondthird party coupon settlement system; receive second value associatedwith the second offer from the second third party coupon settlementsystem; and credit a portion of the second value to the accountassociated with the user.
 19. The one or more computer-readable media asrecited in claim 15, having additional computer-executable instructionsthat, when executed by one or more processors, cause the one or moreprocessors to perform operations to: determine that a second user sharedan instance of the offer with the user based on a chain of titleassociated with the instance; and credit a second portion of thecurrency value to an account associated with the second user.
 20. Theone or more computer-readable media as recited in claim 15, havingadditional computer-executable instructions that, when executed by oneor more processors, cause the one or more processors to performoperations to: receive offer data from one or more merchants; andgenerate the offer based at least in part on the offer data.